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\  Abstxast 

\  • 

^  k  local  computer  for  the  Electronic  Warfare  Division  Engineering 
Branch  Laboratory  was  designed  around  a  commerically  available  and 
supportable  network  configuration.  The  requirements  for  this  network 
were  specified  by  interviewing  the  engineers  associated  with  the 
Engineering  Branch  Laboratory  and  then  translating  the  functional 
requirements  into  a  detailed  set  of  hardware  and  software  system 
requirements.  Structured  Analysis  was  used  to  produce  a  structured 
specification  for  application,  transport,  network,  and  data  link 
protocol  level  requirements . ^  Digital  Equipment  Corporation's  'DECnet1 
Phase  II  and  Phase  III  network  configurations  were  combined  together  to 
form  this  unique  Electronic  Warfare  Network  (EWNET).  The  node  network 
uses  a  loop  topology  with  a  star  of  up  to  seven  hosts  connected  to  each 
node.  The  nodes  are  implemented  using  Digital  Equipment  Corporation's 
PDP-11/70  computers.  Initially,  the  network  will  include  fourteen 
Integrated  Support  Station  computers  which  are  either  Digital 
VAX-11/7808  or  Digital  PDP-ll/34s.  These  computers  will  be  connected  to 
the  nodes  using  duplex  fiber  optic  links  supporting  transmission  rates 
up  to  1  Mbs.  The  Phase  II  DECnet  protocol  was  selected  to  provide  the 
file  transfer  and  data  transport  protocols  in  conjunction  with  a  basic 
routing  algorithm  at  each  host,  while  the  Phase  III  DECnet  protocol  was 
selected  to  provide  these  functions  at  a  higher  level  in  the  nodes.  The 
selection  of  the  above  topology  in  conjunction  with  the  described 
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The  purpose  of  this  thesis  investigation  was  to  design  a  local 
computer  network  for  the  Warner  Robins  Air  Logistics  Center  (WR-ALC) 
Electronic  Warfare  Division  Engineering  Branch.  This  network,  named  the 
Electronic  Warfare  Network  (EWNET),  was  first  proposed  in  1980,  when  the 
number  of  Integrated  Support  Stations  in  the  Engineering  Branch  had 
grown  to  nine.  At  this  time,  there  were  insufficient  peripheral  devices 
plus  engineering  expertise  to  completely  support  existing  and  future 
electronic  warfare  (EW)  efforts.  Local  networks  were  becoming 
invaluable  aids  to  organizations  and  corporations  similar  in  structure 
to  the  EW  Division.  This  was  due  to  a  desire  to  increase  information 
processing  power  without  additional  computers.  Also,  corporations  were 
finding  that  the  shortage  of  electronic  and  software  engineers  was 
causing  project  non-support  to  result  since  multi-system  expertise 
amoung  existing  engineers  was  becoming  next  to  impossible  to  obtain. 
Interest  in  both  of  the  above  areas  plus  the  potential  cost  savings, 
provided  the  impetus  for  the  development  of  a  local  computer  network  for 
the  WR-ALC  EW  Division. 


Historical  Perspective 


For  the  past  decade,  the  field  of  Data  Communications  has  been 
rapidly  changing,  with  important  innovations  emerging  all  the  time.  One 


recent  development  of  wide  ranging  significance  is  the  introduction  of 
several  new  techniques  for  short  distance  high  speed  local  computer 
networks.  By  definition,  a  local  network  is  a  data  communication  system 
designed  to  interconnect  computers  and  terminals  over  a  restricted 
geographical  area,  typically  less  than  2-kilometers  in  diameter  (Ref. 
4:18).  A  number  of  implications  follow  from  this  definition. 

At  a  technical  level,  the  problems  involved  in  designing  local 
networks  are  not  very  different  from  those  relating  to  long  distance 
networks  such  as  the  Advanced  Research  Projects  Agency  Network 
(ARPANET).  However,  the  parameters  are  different.  Since  communication 
is  required  only  over  a  local  region,  the  following  observations  can  be 
made . 


—  A  more  expensive  communication  medium,  in  terms  of  cost  per 
meter,  can  be  used  in  a  local  network  because  the  total  cost  of  tne 
medium  is  likely  to  be  small  compared  to  installation  and  other 
hardware  and  software  costs. 

—  Since  a  more  expensive  communication  medium  can  be  used,  a 
more  powerful  medium  is  possible,  especially  in  terms  of  speed  and 
error  performance.  Thus  the  communication  network  and  communication 
medium  represent  less  of  a  bottleneck  to  the  system  as  compared  to 
geographical  (global)  networks. 

—  Since  the  communication  network  and  transmission  mediums  are 
no  longer  bottlenecks,  transmission  rates  are  higher.  Delivery 
rates  and  maximum  delivery  delays  become  shorter.  The  increased 
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bandwidth  and  shorter  transmission  distance  of  the  communication 
medium  causes  error  rates  to  be  reduced.  Also*  the  short 
transmission  distance  reduces  the  cost  associated  witn 
interconnecting  terminal  and  computer  equipment. 

—  Since  wide  bandwidth  mediums  are  cost  effective  for  use  witn 
local  networks*  greater  use  of  broadcast  or  multi-address 
communications  is  possible.  The  wide  bandwidth  medium  alleviates 
the  problem  of  channel  contention  where  two  or  more  transmitting 
terminals  overlap  on  the  same  channel  (clash). 

—  Local  interface  hardware  and  communication  protocols  can  be 
considerably  simplified  because  there  is  no  need  to  optimize 
available  communications  bandwidth*  since  the  inherent  traffic 
handling  capacity  of  the  network  is  so  much  greater  than  in  a  global 
network. 

—  The  cost  of  interconnecting  a  device  to  a  local  network  can 
be  reduced  by  the  procedures  of  simplification  (no  longer  need 
central  switching  or  control  systems)  and  standardization. 

Only  recently  have  local  networks  been  used  extensively*  therefore 
no  standardization  exists.  One  of  the  most  attractive  possibilities  for 
standardization  is  the  problem  of  a  standard  interface  and  associated 
protocol.  For  example*  the  X.25  Protocol*  which  defines  the  interface 
of  a  computer  to  a  packet-switching  network*  has  just  recently  become  a 
standard  (Ref.  8:108).  Additionally,  one  of  the  most  often  ignored 
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problems  when  considering  the  design  of  a  local  network  is  the  number  of 
levels  of  function-oriented  protocols  necessary  to  accomplish  useful 
work  on  the  network.  In  order  to  be  useful  the  local  network  must 
support  some  form  of  data  transport  protocol*  file  transfer  protocol* 
and  virtual  terminal  protocol.  These  protocols  are  necessary  so  that  a 
computer  which  was  designed  with  one  data  and  file  format*  and  with  a 
particular  terminal  type  in  mind*  can  transfer  data  and  files  to  other 
computers  in  other  formats*  and  accept  information  from  foreign  terminal 
types  (Ref.  4:26). 

Finally*  no  standard  local  computer  network  exists.  In  the  past* 
most  local  computer  networks  available  commercially  were  developed  by  a 
firm  to  support  their  own  systems.  Foreign  device  interfacing  was 
accomplished  through  the  development  of  an  emulator  to  make  the  foreign 
device  appear  at  the  interface  as  one  of  the  manufacturer's  own  devices. 
IBM's  System  Network  Architecture  (SNA)  and  the  Digital  Equipment 
Corporation's  Network  (DECNET)  are  both  examples  of  this  type  of  network 
(Ref.  1:3). 

Recently  developed  by  Xerox  Corporation*  the  ETHERNET  network 
concept*  utilizing  contention-allocation  mechanisms  (packet  collision 
detection)  and  data  packets  on  a  logical  channel*  can  interface  a 
hetergeneous  set  of  computers  together  (Ref.  5:78). 

Thus  local  computer  networks  have  evolved  from  long-distance 
networks  to  meet  the  needs  of  a  local  organization  requiring  internal 
control  of  their  own  systems.  The  local  network  offers  advantages  not 
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accessable  to  organizations  in  the  past.  Even  though  problems  still 
exists*  several  existing  systems  such  as  DECNET,  SNA*  and  ETHERNET  have 
come  a  long  way  in  providing  a  standard  design.  So  it  is  from  this 
viewpoint  that  the  development  of  EWNET  took  place.  The  following 
sections  give  additional  definitions  and  background  necessary  to 
understand  the  EWNET  design  decisions. 


Background 

This  investigation  follows  two  studies  performed  by  the  Georgia 
Institute  of  Technology  Engineering  Experiment  Station  Systems 
Engineering  Laboratory  (Ref.  2,3).  The  Standardized  Integration 
Support  Station  System  Study  (SISS  Study)  was  the  final  standardization 
report  which  identified  the  need  for  the  EWNET  (Ref.  2:8-13).  The 
Standardized  Integeration  Support  Station  System  Specification  (SISS 
Spec)  was  the  final  system  specification  that  resulted  in  several 
general  theoretical  concepts  upon  which  the  network  design  was  based 
(Ref.  3:41-43). 

Both  documents  cover  the  EWNET  in  limited  detail  and  essentially 
state  a  reason  for  the  network  followed  by  a  possible  configuration. 
The  configuration  presented  in  the  SISS  System  Specification  is  based  on 
the  author's  personal  preference  and  not  on  an  actual  study  of  the 
Engineering  Branch  requirements.  Therefore*  additional  work  was 
required  before  a  design  for  EWNET  could  be  developed  and  implemented  in 
the  Engineering  Branch  Laboratory. 
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To  correctly  design  a  local  computer  network,  the  functions  to  be 
supported  by  the  network  must  be  understood  in  context  with  the  existing 
support  equipment. 

Integrated  Support  Stations  (ISS)  are  systems  that  support  the 
efforts  required  to  provide  software  reprogramming  and  hardware  update 
prototyping  for  electronic  warfare  (EW)  systems.  An  ISS  is  not  used  to 
repair  or  test  the  numerous  fielded  EW  systems  of  a  given  type. 

An  ISS  is  divided  into  two  major  parts.  For  convenience,  these  two 
parts  will  be  referred  to  as  the  ISS  Development  System  and  the  ISS 
Control  System.  One  system  controls  the  testing  of  an  operational  EW 
system  modified  for  laboratory  use  (Hot  Mock-up).  The  other  major 
system  supports  the  development  of  the  software  for  the  EW  system.  A 
functional  block  diagram  is  shown  in  Figure  1  on  page  8. 

The  ISS  Development  System  supports  reprogramming  development  for 
the  EW  system  Operational  Flight  Program  (OFP)  software.  The  facilities 
provided  for  development  include  facilities  to  prepare  OFP  software  for 
the  EW  system  and  computers  in  the  ISS,  to  support  distribution  of  OFP 
software  to  the  field,  to  prepare  test  procedures  for  the  EW  system,  and 
to  analyze  results  of  EW  system  tests. 

The  ISS  Control  System  provides  supervisory  control  of  the  ISS, 
automatic  execution  of  EW  system  test  including  stimulus  of  the  EW 
system  Hot  Mock-up  and  response  measurement  system,  an  automatic  test 


and  calibration  of  ISS  stimulus  and  measurement  equipment*  and 
communication  facilities  in  the  ISS  and  to  the  network  of  all  ISSes  and 
other  computers. 

Each  ISS  interfaces  with  the  Advanced  Threat  Simulator  (ATS)  and 
the  Electronic  Warfare  Open  Loop  Simulator  (EWOLS)  and  the  Electronic 
Countermeasures  Signal  Analysis  System  (ECSAS)  for  the  purpose  of 
performing  large  scale  tests  of  the  supported  EW  system.  The  EWOLS  or 
ATS  and  ECSAS  combination  is  a  dense  radio  frequency  (RF)  signal 
enviroment  and  analyzer*  respectively  (Ref.  3:4). 

Each  ISS  has  the  capability  to  operate  independent  of  the  ISS 
network  and  any  common  large  scale  computer.  Therefore*  an  ISS  is  a 
support  station  that  is  built  around  an  advanced  state-of-the-art 
minicomputer  with  special  internal  interfaces  to  the  Hot  Mock-up  to 
control  and  monitor  OFP  software  and  flight  hardware  operation. 

Qbjec.Liye  of  Xhii  Investigation 

The  objective  of  this  investigation  was  to  specify  the  design  of 
the  EWNET  in  "sufficient**  detail  to  obtain  a  network  design  that  met  the 
Engineering  Branch  baseline  need  of  a  local  resource  sharing  network 
that  is  highly  reliable,  through  built-in  redundancy,  and  contains  a 
minimal  amount  of  one-of-a-kind  technology.  To  arrive  at  this  baseline 
design*  the  following  steps  were  followed: 

1.  Survey  of  user  needs  and  requirements. 
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gure  1  SISS  Functional  Block  Diagram 


2.  Determination  of  user  functional  requirements. 


3.  Translation  of  functional  requirements  into  a  system 
specification  through  the  use  of  Structured  Analysis  techniques 
(Ref.  9:55-165). 

4.  Development  of  the  hardware  design 

5.  Specification  of  the  necessary  protocol  within  a 
commercially  available  system  software  design  and 

6.  Evaluation  of  the  Electronic  Engineering  Branch  Laboratory 
Host  processor  (UNIVAC-1108)  off-line  functions  to  determine  if  the 
functions  can  reside  within  the  EWNET  configuration. 

Approach 

The  following  approach  was  used  in  the  design  of  EWNET.  First,  a 
top-dcwn  development  of  the  design  was  chosen.  This  allowed  the  design 
to  first  address  those  levels  closest  to  the  user,  thereby  insuring  that 
the  design  would  be  consistent  with  the  user's  requirements.  Then  the 
lower  levels  of  the  design  were  developed  to  support  the  requirements  of 
the  next  higher  levels. 

Due  to  the  size  of  the  development  effort,  structured  analysis  and 
design  techniques  were  used  in  the  approach  to  provide  clear  written 
specifications  and  diagrams.  Structured  analysis  and  design  techniques 
were  chosen  over  other  techniques  since  they  provide  unambiguous 
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information  about  a  large  design  to  those  implementing  it. 

The  first  phase  of  the  investigation  consisted  of  researching  the 
literature  and  gaining  a  working  knowledge  of  computer  networks, 
protocols,  hardware  interfaces,  and  the  capabilities  of  tne  Engineering 
Branch  Laboratory  ISSes. 

Once  a  sufficient  background  had  been  obtained,  a  user  interview 
was  designed  and  the  ISS  system  lead  engineers  were  interviewed.  From 
these  interviews,  a  set  of  projected  uses  and  functional  requirements 
were  compiled  and  used  to  determine  the  system  requirements. 

The  system  requirements  consist  of  both  hardware  requirements  for 
the  topology,  hosts,  nodes,  and  transmission  mediums,  as  well  as 
software  requirements.  Structured  analysis  was  used  to  document  the 
software  requirements  (Ref.  9).  Data  flow  diagrams  and  a  data 
dictionary  were  used  to  generate  the  structured  specification. 

The  system  requirements  were  then  used  to  develop  a  hardware  design 
and  a  software  design  through  the  study  and  refinement  of  an  existing 
commerically  available  network  configuration.  The  final  stage  of  the 
investigation  included  an  evaluation  of  the  Engineering  Branch 
UNIVAC-1108  functions  (off-line  support,  backup,  and  databases)  and  the 
resulting  decision  to  delete  the  Branch  requirement  to  perform  the 
UNIVAC-1108  functions  on  the  UNIVAC-1108  computer.  Instead,  these 
off-line  functions  will,  in  the  future,  be  performed  by  the  EWNET  node 
computers. 
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The  structure  of  the  thesis  basically  follows  the  approach  that  was 
taken  in  the  investigation. 

Chapter  II  contains  an  analysis  of  the  EWNET  functional 
requirements.  Appendix  A  provides  the  supporting  information  including 
the  compilation  of  the  results  of  the  user  interviews,  ISS  systems  to  be 
supported  by  EWNET,  a  list  of  those  interviewed,  and  their  respective 
areas  of  expertise. 

Chapter  III  translates  the  functional  requirements  into  hardware 
and  software  requirements.  Structured  analysis  is  defined  and  data  flow 
diagrams  are  used  throughout  the  chapter  to  support  the  written 
description  of  the  software  requirements.  Appendix  B  contains  the  floor 
layouts  of  the  location  of  the  EW  systems  to  be  supported  by  EWNET  with 
tentative  locations  identified  for  the  EWNET  node  computers.  The 
Georgia  Institute  of  Technology  proposed  topology  diagrams  are  included 
in  Appendix  B  to  further  clarify  the  floor  layouts  (Ref.  2:10). 
Appendix  C  contains  the  complete  structured  specification  in  support  of 
the  software  requirements. 

Chapter  IV  describes  the  design  phases  of  EWNET.  The  design  of  the 
hardware  is  specified,  including  the  topology  to  be  employed,  the  EW 
systems  to  be  included  in  the  network,  the  nodes  to  be  used  in  the 
network,  and  the  transmission  medium  to  be  used.  The  software  design  is 
described  in  terms  of  a  commercially  available  network  design.  First, 
the  functional  specification  and  requirements  were  used  to  select  the 


best  commercially  available  network  from  a  list  of  three  existing 
designs.  Then  the  selected  design  was  tuned  to  represent  the  exact 
requirements  of  EWNET.  Additionally,  off-line  host  software  was 
allocated  to  the  node  processors.  Finally,  Appendix  D  contains  the 
actual  software  and  hardware  design  in  the  format  required  by  the 
selected  vendor,  so  that  the  Appendix  D  can  be  used  as  the  document 
necessary  to  procure  the  EWNET. 

Chapter  V  summarizes  this  investigation  and  gives  recommendations 
for  follow-on  research  efforts. 
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ULs _ EWNET  Functional  Requirements 


Introduction 

This  chapter  specifies  the  functional  requirements  of  EWNET. 
First,  the  background  of  the  requirements  analysis  is  discussed, 
including  the  reason  it  is  important  to  conduct  a  thorough  investigation 
of  the  functional  requirements.  Then  the  content  of  the  user  survey 
that  was  used  to  help  determine  the  EWNET  requirements  is  described. 
Also  included  in  this  section  is  a  description  of  how  the  survey  was 
conducted  including  personal  observations  about  the  survey  contents. 
The  next  section  summarizes  the  projected  uses  of  EWNET,  followed  by 
sections  summarizing  user-oriented,  design-oriented,  and  additional 
functional  requirements.  Finally,  EWNET  constraints  not  addressed  by 
the  user  survey  are  discussed. 


Background 

Possibly  the  most  crucial  step  in  designing  a  computer  network  is 
the  specification  of  the  network  requirements.  Yet,  this  phase  of 
development  was  completely  overlooked  by  both  the  SISS  Study  and  the 
SISS  System  Specification  (Ref.  2,3).  While  it  is  possible  to  specify 
many  requirements  that  are  generally  desirable  in  a  network,  using  this 
approach  without  additional  thought  will  result  in  a  incomplete  and 
inaccurate  requirements  specifications.  This  is  due  to  the  way  local 
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computer  networks  vary  from  organization  to  organization  (Ref.  4:18). 
This  is  obvious  from  the  many  varied  designs  that  presently  exist  in 
industry.  Also,  not  all  requirements  for  a  network  have  the  same 
weight.  Due  to  time  or  money  constraints,  the  network  may  not  be  able 
to  support  all  requirements.  Some  requirements  add  no  value  to  the 
network  when  considered  for  a  particular  organization's  uses.  Finally, 
every  organization  is  unique  and  would  have  unique  requirements  for 
'their'  network.  These  unique  requirements  would  be  overlooked  if  we 
only  considered  what  is  generally  desired  in  a  network. 


User  Survey 

A  systematic  approach  was  needed  to  specify  the  requirements  for 
EWNET  that  would  tailor  it  to  the  requirements  of  the  Engineering  Branch 
Laboratory.  Thus,  a  four-part  user  survey  was  designed. 

In  the  first  section,  the  users  were  asked  what  applications  could 
be  sewed  by  EWNET  from  their  utilization  perspective.  To  aid  the  users 
being  interviewed,  twelve  common  local  network  applications  were  listed 
which  the  user  could  evaluate  on  a  five-point  scale  from  'OF-NO-USE*  to 
'VERY  GOOD*.  These  applications  included  peripheral  sharing  amoung  the 
computers  in  the  network,  file  accessing  and  transfers  across  the 
network,  sharing  software  tools  on  the  network,  accessing  AUTODIN  I, 
accessing  ARFANET,  accessing  the  UNIVAC-1108  host  installation  computer, 
using  digital  threat  information  generated  from  a  central  location, 
monitoring  Eglin  AFB  flight  test  in  real  time,  doing  distributed 
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processing*  managing  distributed  databases*  monitoring  Eglm  AFB  flight 
test  video*  and  providing  fault  tolerance  for  the  EWNET.  Finally*  this 
section  asked  the  users  to  identify  the  applications  that  they  felt 
should  be  implemented  first  and  to  prioritize  the  applications  in  terms 
of  their  personal  needs  with  any  related  comments. 

The  second  section  asked  the  user  to  estimate  the  requirements  from 
their  perspective  for  six  basic  network  parameters.  The  user-oriented 
parameters  were  throughput*  response  time,  the  user  interface,  security* 
availability  of  the  network,  and  ISS-to-ISS  interaction.  Each  of  the 
subsections  addressing  a  parameter  had  a  number  of  questions  to  aid  the 
user  in  evaluating  the  requirement  for  that  parameter.  Each  user  was 
then  asked  to  identify  any  other  user-oriented  parameters  that  might 
influence  EWNET's  design.  Finally,  the  second  section  concluded  by 
having  the  user  rate  each  of  the  six  parameters  on  a  five-point  scale 
from  ’DOES  NOT  APPLY'  to  'MUST  HAVE'. 

The  third  section  asked  users  to  make  any  other  comments  that  they 
felt  might  help  specify  the  requirements  of  EWNET. 

The  fourth  section  asked  the  general  branch  management  to  estimate 
the  design- oriented  functional  requirements  of  EWNET  since  no  single 
network  management  group  existed  within  the  Engineering  Branch.  Three 
basic  network  design-oriented  parameters  were  listed.  They  were 
flexibility*  performance  monitoring,  and  the  availability  of  a 
distributed  processing  language.  As  with  the  user-oriented  parameters, 
each  subsection  contained  a  number  of  questions  to  help  management  to 
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evaluate  the  parameter.  Management  was  also  asked  to  identify  other 
design-oriented  parameters  and  conclude  the  section  by  rating  each  of 
the  three  parameters  on  a  five-point  scale  from  ’DOES  NOT  APPLY’  to 
'MOST  HAVE’. 


The  user's  of  EWNET  were  addressed  as  being  the  ISS  system  lead 
engineers,  section  leaders,  and  the  branch  chief.  The  users  were  sent 
the  'EWNET  INTERVIEW’  survey  two  weeks  prior  to  the  actual  interviews 
being  conducted.  This  was  done  to  give  the  users  time  to  develop  their 
own  questions  about  the  survey. 

Each  user  was  interviewed  for  approximately  fifty  minutes  using  the 
user  survey  forms  sent  to  them  two  weeks  prior.  Personal  interviews 
were  selected  to  allow  the  user  to  completely  understand  the  survey  by 
asking  direct  questions  to  the  interviewer.  Also,  the  interviewer  was 
able  to  help  the  user  weigh  his  answers  to  the  survey  questions.  The 
response  to  the  user  interviews  was  excellent  and  the  information 
obtained  was  used  to  formulate  the  general  requirements  specifications 
that  follow. 


Eroiectjed  Ifaefl  of  EWNEX 

The  initial  uses  of  EWNET  as  presented  in  The  Standardized 
Integration  Support  Station  System  Specification"  are  as  follows  (Ref. 
3:8): 


4 
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1.  Threat  data  access  =  access  by  every  ISS  to  the  Standard 
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Threat  Database  hosted  on  the  Electronic  Warfare  Branch  Rost 
Computer  (UNIVAC-1108) . 

2.  Hardware  resource  sharing  =  ability  to  use  other  ISS's 
hardware  through  the  use  of  the  network. 

3.  Software  resource  sharing  =  ability  of  each  ISS  to  use  a 
common  depository  of  software  tools. 

4.  Supplemental  analysis  =  The  ability  of  each  ISS  to  perform 
off-line  time-consuming  supplemental  analysis  processing 
(flight-test  data  reduction)  on  the  Electronic  Warfare  Branch  host 
computer. 

5.  Back-up  processing  =  in  the  event  of  a  complete  ISS 
computer  failure,  the  ability  to  continue  with  EW  support  through 
the  use  of  the  network  and  the  Electronic  Warfare  Branch  host 
computer.  Finally,  the  network  will  be  used  as  one  of  the 
instruments  to  bring  about  complete  standardization  of  the 
Engineering  Branch  Laboratory. 

The  user  survey  results  were  used  to  determine  the  projected  uses 
of  EWNET.  The  principal  uses  that  were  considered  most  beneficial  were 
in  the  area  of  resource  sharing.  Peripheral  sharing,  file  access  and 
transfer,  software  tool  sharing,  and  access  to  the  UNIVAC-1108  were 
identified  by  all  users  as  being  of  top-priority.  Next  in  potential 
benefits  was  the  capability  of  executing  job  processes  that  can  run 
concurrently  on  different  computers  (distributed  processing)  and  the 
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capability  to  access  and  maintain  distributed  databases.  Access  to 
ARPANET  and  to  AUTODIN  I  through  the  use  of  EWNET  was  completely 
rejected  because  the  security  of  the  Engineering  Branch  allowed  no 
external  (outside  immediate  building  area)  gateways  to  the  ISSes. 
Access  to  Eglin  AFB  flight  test  data  (digital  and  video)  was  looked  upon 
as  a  very  nice  capability  but  noc  required  for  the  immediate  future  due 
to  the  cost  incurred  in  obtaining  a  dedicated  satellite  plus  encryption 
and  decryption  devices,  receivers,  and  transmitters.  Access  to  a  remote 
digital  threat  generator  was  rejected  because  most  ISSes  already  have  a 
local  capability  and  those  that  do  not  are  in  the  process  of  developing 
this  capability.  Finally,  the  network  is  expected  to  support  critical 
functions,  therefore,  the  users  perceived  that  a  need  would  arise  for 
the  network  to  guarantee  uninterrupted  service  to  the  ISSes  through 
redundancy  and  fault-tolerance.  The  projected  uses  of  EWNET  are 
summarized  in  Table  1 . 

User-Oriented  Functional  Requirements 

The  user's  functional  requirements  were  also  obtained  from  the 
survey.  The  throughput  indicated  by  the  users  required  the  data  rates 
in  the  network  to  be  a  minimum  of  1  million  bits  per  second  per 
transmission  link.  Data  rates  between  the  Host  computer  and  the  other 
computers  in  the  network  should  be  a  minimum  of  56.000  bits  per  second 
per  transmission  link.  Usage  of  the  computers  in  the  Engineering  Branch 
Laboratory  will  average  between  6  to  10  hours  per  day  with  peaks  of  up 
to  24  hours  a  day  for  all  ISSes  during  ofticial  OFF  change  exercises. 


«  * 
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These  exercises  are  staggered 


I  PROJECTED  USE 

I 

I  VERY 

I  GOOD 

GOOD 

MEDIUM 

1  LITTLE 

1  USE 

NO 

USE 

1 

1 

I  PERIPHERAL  SHARING 

1  5 

4 

2 

1  1 

0 

1 

1  FILE  TRANSFERS 

1  8 

2 

1 

1  1 

1 

1 

1  SOFTWARE  TOOL  SHARING 

1  8 

3 

1 

1  0 

0 

1 

I  ACCESS  TO  UNIVAC-1108 

1  5 

4 

1 

1  1 

2 

1 

I  ACCESS  TO  ARPANET 

1  0 

0 

0 

1  4 

8 

1 

1  ACCESS  TO  AUTODIN  I 

1  1 

1 

2 

1  0 

8 

1 

I  THREAT  GENERATOR 

1  4 

5 

1 

1  3 

1 

1 

I  FLIGHT  TEST  MONITOR 

1  2 

1 

3 

1  3 

3 

1 

1  DISTRIBUTED  PROCESSING 

1  2 

3 

4 

1  3 

0 

1 

I  DISTRIBUTED  DATABASES 

1  2 

3 

4 

I  4 

0 

1 

I  VIDEO 

1  1 

2 

3 

1  2 

4 

1 

1  FAULT  TOLERANCE 

1  4 

7 

2 

1  0 

0 

1 

Table  1  Projected  Uses  of  EWNET  (Composite  of  User  Responses) 


throughout  each  year  and  usually  only  two  thirds  of  all  ISSes  are 
affected.  The  ISS  computers  being  affected  by  heavy  usage  at  the 
present  time  are  listed  below. 

1.  Harris  6024/4 

2.  VAX  11/780 
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3.  PDP  11/34 


4.  Mod comp  Classic 

5.  Data  General  Ellispe  S-230 

These  ISS  computers  are  the  presently  used  computers.  Future 
standardization  plans  (by  1984)  require  that  all  ISS  host  computers 
will  be  one  of  the  models  from  the  Digital  Equipment  Corporation 
line  of  computers  (Ref.  3:17-20). 

The  response  time  requirement  was*  of  courset  closely  tied  to  the 
throughput  requirement.  The  requirement  for  response  time  was  addressed 
for  three  modes:  interactive,  file  transfers,  and  echoing  user  inputs. 
In  the  interactive  mode,  two  to  three  seconds  for  'simple'  commands  was 
considered  to  be  satisfactory.  For  file  transfers,  the  response  time 
was  set  to  five  minutes  for  a  32  Kbyte  file.  Also,  each  ISS  will 
require  the  ability  to  obtain  and  verify  a  copy  of  the  Standard  Threat 
Database  from  an  installation  host  computer  through  the  network  within 
20  minutes.  This  was  considered  an  acceptable  tradeoff  between  user 
requirements  and  the  file  accessing  capabilities  of  the  computers  in  the 
Engineering  Branch  Laboratory.  The  echo  response  time  was  given  as  a 
maximum  of  one-half  second.  This  was  to  insure  that  the  echos  of  the 
user  inputs  did  not  interfere  with  their  entering  subsequent  data  at  the 
terminal  keyboard.  All  response  time  requirements  seemed  consistent 
with  the  results  of  psychological  studies  predicting  satisfactory  levels 
of  performance  for  the  typical  user  (Ref.  6:322-323).  An  additional 
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requirement  on  the  response  time  addressed  consistency  in  the  response 
times. 


Other  user  interface  requirements  of  equal  importance  included 
error  recovery*  built-in-test*  user  'help*  command  capabilities*  and  an 
in-house  distribution  capability  so  that  messages  from  one  ISS  to 
another  could  be  transmitted  point-to-point.  Also*  a  management 
distribution  capability  was  recommended.  In  this  case  a  message  would 
be  sent  from  someone  at  an  ISS  to  perhaps  a  stand-alone  terminal  located 
at  a  central  management  point.  All  users  stressed  the  importance  of 
maintaining  ISS  independence  from  the  network  in  case  there  was  a 
network-wide  failure  the  individual  iSSes  could  continue  to  function. 
Finally,  all  users  indicated  that  iSS-to-network  accounting  data  would 
be  a  requirement,  especially  if  it  would  provide  them  with  the  number  of 
times  their  ISS  was  being  externally  accessed  over  any  given  day. 

Security  was  addressed  from  four  perspectives.  All  users  indicated 
that  'Secret1  data  would  be  running  on  the  network  and  on  the  ISSes. 
Therefore,  the  concensus  was  that  the  network  would  require  a  design  to 
safeguard  the  processing  of  classified  data.  The  second  aspect  of 
security  addressed  was  the  requirement  to  protect  files  on  the  network 
from  unauthorized  access  or  alteration.  It  is  highly  undesirable  for 
all  ISSes  to  have  unlimited  access  to  all  classified  files  without  some 
means  of  control  and  need-to-know  establishment  for  the  particular  data. 
Thus*  file  access  restrictions  were  found  to  be  a  security  requirement 
for  the  network.  A  two  element  file  password  to  protect  this 
need-to-know  was  suggested.  And  as  a  matter  of  security  accountability 
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it  vaa  suggested  that  the  ISS/netvork  interface  accounting  package 
should  record  time,  destination,  and  password  of  all  classified 
recipients  (each  access).  This  would  also  be  of  benefit  to  audits  of 
ISS  classified  activity  when  problems  arose.  The  third  aspect  of 
security  was  related  to  the  electromagnetic  interference  (EMI)  generated 
by  the  network  mediums.  All  users  indicated  that  fiber  optic  based 
systems  should  be  used  as  the  network  medium,  where  possible,  because 
fiber  optic  based  systems  are  less  susceptible  to  EMI  than  systems  using 
traditional  metallic  connections.  The  f  ’irth  and  final  aspect  of 
security  was  access  control  to  the  network  from  outside  the  Engineering 
Branch  Laboratory.  As  discussed  before,  all  users  inuicated  that  such 
gateways  could  not  be  allowed  due  to  the  restrictions  placed  on  the  ISS 
internal  security. 

The  availability  of  EWNET  was  defined  to  be  the  percentage  of  time 
that  the  network  provided  the  capabilities  required  by  a  particular  user 
as  compared  to  the  time  that  it  was  suppose  to  provide  those 
capabilities.  This  definition  resulted  in  assessments  ranging  from  50 
percent  to  100  percent  with  100  percent  being  the  answer  given  by  almost 
half  of  the  users.  The  time  periods  that  the  network  should  be 
available  were  identified  as  either  normal  duty  hours  (0800-1700)  or 
during  times  when  emergency  OFF  changes  would  require  duty  to  extend 
beyond  normal  hours.  The  90  percent  availability  level  was  finally 
determined  to  be  acceptable  considering  the  network  should  be  available 
90  percent  of  a  24  hour  day,  leaving  10  percent  of  the  24  hour  day  for 
maintenance  downtime.  This  90  percent  availability  level  represents  a 
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reasonable  target  for  the  system  design. 

ISS-to-ISS  interaction  was  considered  to  be  of  minimual  importance. 
Host  users  felt  that  ISS-to-ISS  interaction  within  a  section  (type  of 
ISS)  would  be  beneficial  but  that  external  section  interaction  would  not 
be  needed.  This  internal  section  ISS-to-ISS  interaction  directly 
corresponds  to  the  suggestion  that  ISS-to-ISS  interaction  take  place 
only  around  a  node  computer  and/or  with  the  installation  host  computer. 

Other  user-oriented  requirements  included  a  word  processor 
capability  plus  central  network  documentation  located  on  a  installation 
host  computer.  A  common  network  command  language  was  also  thought  to  be 
important  to  minimize  confusion.  A  real-time  network  capability  where 
one  ISS  took  complete  control  of  the  network  when  emergency  changes 
dictated  it  was  suggested.  Finally,  for  future  consideration,  a  data 
link  to  EW  Elint  sources,  overflow  /  surge  load  handling  (using  another 
ISS's  terminals  to  operate  your  ISS),  and  selt-conf iguration  through 
periodic  status  checks  of  the  network  members  were  other  suggestions 
made  but  were  felt  to  be  of  little  immediate  importance.  Table  2 
summarizes  the  user-oriented  functional  requirements. 

Design-Oriented  Functional  Requirements 

The  design-oriented  functional  requirements  included  flexibility, 
performance  monitoring,  and  distributed  processing  language.  The 
flexibility  requirement  was  addressed  by  asking  management  to  describe 
how  they  would  see  the  network  changing  over  the  next  five  years.  The 
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AREA 

1 

MUST 

1 

VERY 

APPLY 

1 

MARGIN 

1 

NOT 

1 

HAVE 

1 

APPLY 

1 

APPLY 

1 

APPLY 

THROUGHPUT 

1 

3 

1 

7 

3 

1 

0 

1 

mm 

RESPONSE  TIME 

1 

3 

1 

7 

2 

1 

1 

1 

0 

USER  INTERFACE 

1 

8 

1 

4 

2 

1 

0 

1 

SECURITY 

1 

12 

1 

0 

0 

1 

in 

1 

0 

AVAILABILITY 

i 

5 

1 

4 

4 

1 

1 

ISS-TO-ISS  INTERACTION 

1 

1 

i 

2 

1 

1 

4 

1 

4 

Table  2  User-Oriented  Functional  Requirements  (Composite  of  User  Responses) 


response  given  by  management  was  that  more  nodes  and  ISSes  would  be 
added  to  the  network.  Management  felt  that  it  was  very  important  for 
EWNET  to  be  easily  reconf igurable  with  respect  to  adding  additional 
nodes  and  ISSes.  Other  changes  mentioned  included  increased  use  of  the 
network  for  management  functions,  and  a  transition  of  the  network 
workload  from  predominantly  file  transfers  to  more  interactive  traffic. 
All  users  expressed  the  concern  that  the  network  should  start  small  with 
limited  capabilities  and  as  new  uses  are  identified  as  being  valuable  to 
the  organization,  the  changes  could  be  implemented  into  the  network  with 
minimum  effort.  Flexibility  with  respect  to  the  topology,  protocols, 
and  transmission  medium  was  considered  to  be  important  only  to  the 
extent  of  the  changes  necessary  to  these  areas  when  additional  nodes  and 
ISSes  were  added  to  the  network. 

The  need  for  some  form  of  performance  monitoring  capability  was 
expressed  by  management,  but  they  felt  that  the  limited  knowledge  on 
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their  part  would  only  confuse  the  matter.  Generally,  management  felt 
that  accounting  data  should  be  available  on  the  network  plus  node 
statistics,  a  software  monitor,  and  a  way  to  detect  network  bottlenecks. 
The  requirement  for  a  performance  monitoring  node  was  rejected, 
management  felt  that  to  protect  the  network  from  slowdown  that 
pertormance  monitoring  should  be  done  only  on  a  demand  basis. 

The  need  for  a  distributed  processing  language  has  been  a  topic  of 
much  discussion  between  the  Air  Force  Logistic  Command  Headquarters  and 
the  Electronic  Warfare  Branch  at  Robins  AFB.  The  Embedded  Computer 
Standardization  Program  Office  established  7  January  1981,  as  the  single 
Air  Force  Office  responsible  for  the  acquisition  of  software  tools  for 
users  of  computers  designed  to  M1L-STD-1750A  (Instruction  Set 
Architecture)  is  to  provide  support  to  Air  Force  Logistic  Command  (AFLC) 
to  develop  a  Jovial  J-73  compiler  for  the  VAX  11/780  computer.  This 
office  and  Jovial  J-73  will  be  used  to  assist  the  Air  Force  in  the 
transition  from  currently  used  higher  order  languages  (HOL)  to  the 
tri-service  HOL  of  the  future  -  ADA  (Ref.  7:3).  Due  to  the  above, 
management  feels  that  all  ISS  host  computers  will  be  required  to 
implement  Jovial  J-73.  Fortran,  and  eventually  ADA  programming  languages 
on  the  network  host  computers.  ADA  will  become  the  distributed 
processing  language  at  WR-ALC.  Table  3  lists  how  management  ranked  each 
of  the  design-oriented  functional  requirements  on  a  scale  from  ’DOES  NOT 


APPLY’  to  ’MOST  HAVE’ 


4  4 


-  .  I** 
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I  AREA  I  MUST  I  VERY  |  APPLY  |  MARGIN  I  NOT  I 

I  I  HAVE  i  APPLY  |  I  APPLY  I  APPLY  I 

I  PERFORMANCE  MONITORING  I  2  I  3  I  4  I  0  I  0  I 

I  DIST.  PROCESS  LANGUAGE  I  2  I  1  I  6  I  0  I  0  I 

I  FLEXIBILITY  I  4  I  3  I  2  I  0  I  0  I 

Table  3  Design-Oriented  Functional  Requirements  (Composite  of  User  Responses) 
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Additional  Functional  Requirements 

The  Third  section  of  The  user  interview  was  used  by  users  and 
management  alike  to  list  additional  requirements  for  the  network.  The 
ability  to  find  a  file  in  the  network  that  had  been  sent  from  one  host 
to  another  was  felt  to  be  an  important  requirement.  The  network  being 
used  for  general  software  development  and  the  network  implementation 
being  started  with  limited  capabilities,  planning  for  future  growth, 
were  two  requirements  that  were  well  accepted.  Requirements  such  as 
being  able  to  initialize  the  network  with  an  arbitary  subset  of  nodes, 
the  location  and  number  of  nodes,  and  the  number  of  ISSes  per  node  were 
areas  where  most  users  had  no  established  opinions.  As  a  final 
requirement,  management  felt  that  the  network  access  should  be  protected 
through  the  use  of  a  network  password. 

Constraints  on  EWNET 

The  network  described  in  this  thesis  will  be  required  to  operate 
successfully  in  an  enviroment  characterized  by  significant  levels  and 
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amounts  of  electromagnetic  interference  (EMI).  All  network  equipments, 
systems,  subsystems,  and  modules  shall  be  able  to  perform  as  specified 
within  the  EMI  enviroment  while  not  permitting  any  performance 
degradation  or  erroneous  data  and  signals  to  be  introduced.  MIL-STD-461 
should  be  used  as  a  guideline. 

Additionally,  the  communication  subsystem  shall  be  capable  of 
reconfiguration  to  remove  and  add  optional  communication  linxs  and  ISS 
subsystems,  control  of  different  types  of  communication  interface 
hardware,  and  controlling  different  types  of  communication 
configurations  (Star,  Ring,  and  Bus  networks)  simultaneously. 

The  physical  layout  of  the  ISSes  plus  nodes  had  to  be  addressed. 
Appendix  B  gives  the  floor  layout  diagrams  for  the  Engineering  Branch 
Laboratory  with  ISS  and  node  locations  identified.  The  maximum 
ISS-to-node  separation  is  200  feet.  The  maximum  node-to-node  separation 
is  300  feet  since  the  Engineering  Branch  Laboratory  is  made  up  of  three 
floors  of  equipment.  These  figures  will  hold  true  in  future  EW 
laboratory  expansion  efforts. 

The  design  goal  for  the  network  for  Meam-Time-To-Restore  (MTR) 
should  be  determined.  MTR  instead  of  Mean-Time-To-Repair  (MTTR)  is  used 
to  indicate  a  return  to  an  operational  state  for  the  network  by 
replacing  major  subsystems  of  the  network.  All  software  must  be 
thoroughly  documented  and  the  hardware  should  be  designed  for  easy 
modular  replacement. 
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As  a  final  constraint  on  EWNET,  network  reliability  will  be 
addressed  in  the  design.  History  generally  indicates  there  is  improved 
reliability  where  design  goals  are  established  prior  to  development 
versus  where  reliability  is  a  fallout  of  the  system  design.  The 
following  are  realistic  design  goals  which  address  reliability  (Ref. 
10:15): 


1.  Failure  of  a  particular  node  will  not  render  the  network 
inoperative. 

2.  Optional  or  alternative  interconnection  paths  between  nodes 
can  be  established  and  assured  if  the  primary  or  direct  path  is 
inoperative. 

3.  Stored  data  will  be  preserved  in  spite  of  electrical 
failure. 


Summary. 


Due  to  the  results  obtained  through  the  use  of  the  user  survey  it 
was  possible  to  specify  a  comprehensive  list  of  functional  requirements 
and  estimate  their  relative  importance.  The  aspects  of  resource  sharing 
was  the  most  important  use  that  the  users  wished  to  see  implemented 
first.  User-interface  and  security  were  considered  the  most  important 
user-oriented  functional  requirements,  while  flexibility  was  considered 
the  most  important  design-oriented  functional  requirement.  Finally, 
EMI,  communication  subsystem,  and  physical  layout  considerations  were 
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accessed.  Appendix  A  contains  a  complete  compilation  of  tne  user  survey 
results . 

Chapter  III  documents  the  translation  of  the  general  functional 
requirements  identified  by  this  chapter  into  more  detailed  system 
specifications. 


III. — EWNET  Svshem  Requirements 


Introduction 

This  chapter  translates  the  general  functional  requirements 
identified  in  the  last  chapter  into  more  detailed  system  specifications. 
The  first  section  of  this  chapter  addresses  the  system  hardware 
requirements  while  the  second  section  specifies  the  system  software 
requirements.  The  hardware  system  requirements  addressed  are  tne 
network  topology,  the  host  computers  to  be  included  in  the  network,  the 
selection  of  a  suitable  node  computer  for  the  network  and  the  choice  of 
an  appropriate  transmission  medium  for  the  EWNET  communication  links. 
The  system  software  requirements  are  specified  using  DeMarco's 
Structured  Analysis  technique  (Ref.  9).  A  description  of  the 
components  of  the  technique  is  given  and  its  use  is  justified.  Then, 
the  structuring  technique  used  to  arrive  at  the  proposed  protocol 
hierarchies  is  described  (Ref.  11:10-21).  Using  the  Structured 
Analysis  techniques  described,  the  system  software  requirements  are 
specified  at  the  defined  protocol  hierarchic  levels.  Finally,  the 
physical  protocol  specifications  are  stated. 

The  requirements  specification  was  actually  an  iterative  process. 
While  some  of  the  specifications  found  in  this  chapter  could  be  derived 
directly  from  the  functional  requirements,  many  actually  followed  from 
design  decisions  made  in  the  following  chapter.  These  requirements 
would  then  trigger  new  design  decisions  which  might  in  turn  modify  the 
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requirements  specification  further.  What  follows  is  the  final  results 
of  this  iterative  process. 


System  Hardware  Constraints 

The  functional  requirements  of  Chapter  II  were  used  to  derive  the 
following  detailed  specifications  of  the  hardware  that  was  required  for 
EWNET.  This  was  done  by  considering  how  the  functional  requirements  of 
the  system  place  constraints  on  the  system  hardware.  These  constraints 
were  then  used  to  derive  the  more  detailed  hardware  specifications. 

Topology.  The  primary  requirement  for  the  topology  was  that  the 
topology  had  to  be  flexible,  and  must  be  easy  to  expand  through  the 
addition  of  more  hosts  and  nodes.  Additionally,  since  availability  was 
of  major  concern,  the  topology  had  to  contain  built-in  redundancy  which 
would  not  be  degraded  when  one  of  the  host  (ISS)  computers  decided  to 
drop  out  of  the  network  (voluntarily  or  involuntarily).  The  topology 
also  must  not  contain  bottlenecks  that  will  limit  the  throughput  on  the 
network  below  the  stated  level  or  that  will  increase  the  response  time 
to  an  unacceptable  high  level  due  to  queueing  delays.  The  response  time 
requirement  may  also  impact  the  topology  by  limiting  the  number  of  nodes 
between  any  two  host  computers  since  the  combined  queueing  delays  may 
increase  the  response  time  to  an  unacceptable  level. 

Host  Computers.  The  requirements  for  the  host  (ISS)  computers  to 
be  included  in  EWNET  was  directly  related  to  their  need  to  access 
centrally  located  databases,  their  level  of  standardization,  and  their 
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peripheral  power.  EWNET  must  meet  all  standardization  requirements 


presently  defined  within  the  Engineering  Branch  Laboratory.  Therefore, 
the  level  of  host  computer  sophistication  and  standardization  must  be  as 
defined  in  the  Standardized  Integration  Support  Station  System 
Specification"  (Ref.  3).  Finally,  the  usefulness  of  the  network  would 
be  enhanced,  if  those  host  computers  used  most  often  in  the  Engineering 
Branch  Laboratory  were  included  in  EVNET. 

Nodes ■  The  requirements  for  the  nodes  in  the  network  also  were 
addressed.  Since  the  host  (ISS)  computers  must  be  able  to  drop  out  of 
the  network  at  anytime  without  degrading  the  network  capabilities,  the 
host  (ISS)  computers  can  not  act  as  the  node  computers.  Therefore,  all 
node  computers  must  be  individual  stand-alone  computers  that  meet  all 
the  standardization  requirements  defined  in  the  Standardized 
Integration  Support  Station  System  Specification"  (Ref.  3).  Because 
EWNET  is  to  be  an  off-the-shelf  standardized  local  computer  network,  all 
centrally  located  databases  and  backup  ISS  functions  should  be  hosted  on 
a  Standard  Engineering  Branch  Computer  (Ref.  3:16-21).  Therefore,  it 
should  be  possible  to  combine  the  Engineering  Branch  Installation  Host 
Computer  function  with  the  EWNET  Node  Computer  function,  given  a 
sufficiently  sophisticated  computer.  This  implys  that  the  node 
computers  must  be  capable  of  handling  lower-level  network  protocols. 
The  nodes  should  contain  their  own  set  of  peropherals  to  provide  backup 
peripheral  capability  for  the  ISSes  plus  to  be  used  when  accessing  the 
node  computer  directly.  Furthermore,  the  node  should  have  the 
capability  to  collect  performance  monitoring  statistics.  Finally,  a 
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compiler  should  be  available  for  the  node  CPU  so  that  the  protocol 
software  may  be  written  in  a  higher  order  language.  This  would  reduce 
the  magnitude  of  the  implementation  effort  and  enhance  the 
maintainability  of  the  software. 

Transmission  Medium.  There  were  several  system  requirements  for 
the  transmission  medium.  First,  it  must  support  the  data  transmission 
rates  necessary  to  meet  the  throughput  and  response  time  requirements. 
Second,  it  must  provide  reliable  communication  links  to  avoid  degrading 
throughput  and  response  times.  Otherwise,  if  a  high  percentage  of 
blocks  of  data  required  retransmission  then  both  response  time  and 
throughput  would  suffer.  The  same  is  true  when  forward  error  correction 
is  used  and  a  high  degree  of  redundancy  is  required  (Ref.  12:202-208). 
However,  the  primary  constraint  on  the  transmission  medium  is  that  it 
must  provide  secure  communications  in  conjunction  with  a  high  noise 
immunity.  Finally,  the  transmission  medium  should  be  easily  re-routed 
to  allow  the  topology  to  be  reconfigured  with  network  growth. 


Software  Specification,  Tools 

Introduction.  While  the  user  surveys  provided  an  excellent  tool 
for  specifying  the  functional  requirements  for  EWNET,  and  some  of  the 
more  hardware-related  system  requirements,  a  technique  was  required  to 
translate  the  EWNET  functional  requirements  into  system  software 
requirements.  Techniques  available  for  this  task  included  DeMarco's 
Structured  Analysis  Technique,  SofTech's  Structured  Analysis  and  Design 
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Technique  (SADT),  IBM’s  Hierarchical  Input-Process-Output  (HIPO) 
diagrams •  and  various  problem  statement  languages  (Ref.  9).  DeMarco’s 
Structured  Analysis  technique  was  chosen  since  it  offered  several 
advantages  over  the  other  methods .  But  before  these  advantages  can  be 
understood,  it  will  be  necessary  to  understand  the  basic  components  of 
the  Structured  Analysis  technique. 

Structured  Analysis.  Structured  Analysis  is  a  technique  using  data 
flow  diagrams  (DFDs)  and  a  data  dictionary  which  uses  Structured 
English,  decision  tables,  and  decision  trees  to  describe  the  DFDs.  The 
data  flow  diagram  ia  a  graphic  tool  used  to  depict  the  logical  flow  of 
data  through  a  program  or  a  system.  The  basic  components  of  a  DFD  are 
shown  in  Figure  2,  page  35.  The  first  component  is  the  data  flow.  It 
is  a  ’'pipeline”  of  other  data  flows  and  of  data  elements.  The  data 
elements  are  the  basic  data  types  that  can  not  be  partitioned  further 
and  still  retain  their  meaning.  The  data  flow  /  elements  are  identified 
as  the  labeled  arrows  that  connect  the  circles  on  the  DFDs.  The  circles 
on  the  DFDs  are  known  as  transforms  (each  identifying  a  function  that 
transforms  data).  Transforms  convert  input  data  flows  to  output  data 
flows  and  is  the  second  component  of  the  DFDs.  The  boxes  represent  any 
mechanism  by  which  information  enters  or  leaves  the  system.  Finally, 
files  are  the  last  component  and  are  repositories  of  information  within 
the  system.  They  are  depicted  by  stright  lines.  Access  to  and  response 
from  a  file  is  depicted  by  a  pair  of  unlabeled  arrows.  The  arrow  to  the 
file  represents  the  search  argument.  The  arrow  from  the  file  represents 
retrieved  information  or  status.  The  DFDs  are  layered  starting  with  an 
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gure  2  DM)  Components 


overview  DFD.  The  overview  DFD  is  used  to  show  on  one  page  the  major 
processes  required  in  a  system.  These  processes  normally  must  be  broken 
down  to  show  the  detailed  processing  requirements  within  each  major 
function.  To  understand  the  detail  of  a  given  process  you  should  refer 
to  a  DFD  with  the  same  numerical  prefex  as  the  process  in  question. 
Each  process  on  the  "parent”  diagram  is  a  consolidation  of  the  network 
shown  on  the  child"  diagram.  The  partitioning  of  the  processes 
continues  until  the  data  flows  entering  and  leaving  a  process  consist  of 
only  one  data  element  each.  At  this  point,  a  process  description  is 
written  for  the  process  and  the  process  is  not  expanded  into  a 
lower- level  diagram.  The  process  descriptions,  data  flow  and  element 
descriptions,  and  file  descriptions  for  all  the  DFDs  are  compiled  into 
the  data  dictionary. 

Using  the  above  "working"  definition  of  Structured  Analysis,  it  is 
now  possible  to  examine  the  advantages  that  Structured  Analysis  offers. 
First,  it  was  based  upon  the  concept  of  partitioning.  This  facilitates 
Top-Down  analysis,  as  major  user  functions  are  decomposed  into  their 
subfunctions.  Thus,  allowing  the  large  and  complex  EWNET  requirements 
problem  to  be  approached  in  an  orderly  manner  rather  than  causing  the 
engineer  to  be  overwhelmed  by  the  vast  amount  of  requirements  to  be 
specified.  Second,  the  data  dictionary  focuses  on  data  flows  rather 
than  on  processes,  resulting  in  clearly  defined  interfaces.  Third,  the 
process  definitions  could  be  easily  specified  using  Structured  English, 
a  tool  incorporated  into  Structured  Analysis.  Fourth,  redundancy  in  the 
Structured  Specification  is  eliminated  due  to  the  organization 
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associated  with  the  DFD  /  data  dictionary  combination.  This  made  the 
task  o£  maintaining  the  specification  and  changing  it  much  easier. 
Fifth,  the  data  flow  diagrams  were  a  two-dimensional  presentation  of  the 
requirements,  thus  presenting  the  structure  in  a  much  clearer  manner 
than  would  otherwise  be  possible  using  the  traditional  linear  and 
voluminous  specification  approach.  Sixth,  Structured  Analysis 
differentiated  between  the  logical  and  the  physical  enviroment,  thus 
allowing  the  functional  software  requirements  to  be  specified  without 
being  concerned  about  the  actual  hardware  that  would  execute  those 
requirements.  Finally,  it  was  easier  to  spot  inconsistencies  and  gaps 
in  the  structured  specification  and  to  correct  those  deficiencies.  The 
major  disadvantage  was  that  it  was  time  comsuming  to  generate  the  DFDs. 


fnatocol  Hierarchies 

Introduction,  now  that  we  have  discussed  the  need  for  using 
Structured  Analysis  in  the  specification  phase,  it  becomes  apparent  that 
a  method  would  be  required  whereby  the  different  software  protocol 
functions  could  be  further  layered  to  facilitate  easier  implementation. 
In  keeping  with  standardization  efforts  (worldwide),  it  was  decided  to 
layer  the  protocols  for  EWNET  using  the  International  Standards 
Organization  (ISO)  model  for  network  protocols  (Ref.  11:15-16).  The 
Reference  model  of  Open  Systems  Interconnection  (OSI),  as  ISO  calls  it, 
has  seven  layers  as  shown  in  Figure  3,  page  38  (Ref.  11:16).  They  are 
the  physical  layer,  the  data  link  layer,  the  network  layer,  the 
transport  layer,  the  session  layer,  the  presentation  layer,  and  the 
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gure  3  ISO  OSI  Network  Architecture  Model 


application  layer 


Physical  Laver.  This  layer  is  concerned  with  transmitting  raw  bits 
over  a  communication  channel. 

Data  Link  Laver.  The  task  of  the  data  link  layer  is  to  take  a  raw 
transmission  facility  and  transform  it  into  a  link  that  appears  free  of 
transmission  errors  to  the  network  layer.  It  accomplishes  this  task  by 
breaking  the  input  data  up  into  data  frames,  transmitting  the  frames 
sequentially,  and  processing  the  acknowledge  frames  sent  back  by  the 
receiver. 

Network  Laver.  This  layer  determines  the  chief  characteristics  of 
the  host-to-node  computer  interface,  and  how  packets,  the  units  of 
information  exchange  in  layer  3,  are  routed  within  the  subnet. 

Transport  Laver.  The  basic  function  of  this  layer,  is  to  accept 
data  from  the  session  layer,  split  it  up  into  smaller  units,  pass  these 
to  the  network  layer,  and  ensure  that  the  pieces  all  arrive  correctly  at 
the  other  end. 

Session  Laver.  The  session  layer  is  the  user's  interface  into  the 
network.  It  is  with  this  layer  that  the  user  must  negotiate  to 
establish  a  connection  with  a  process  on  another  machine. 

Presentation  Laver.  The  presentation  layer  performs  functions  that 
are  requested  sufficiently  often  to  warrent  finding  a  general  solution 
for  them,  rather  than  letting  each  user  solve  the  problems. 


Application  Laver.  This  layer  is  used  to  control  remote  file 
access*  network  access,  and  to  manage  any  statistical  functions  on  the 
network. 

Finally,  it  should  be  noted  that  the  session  lager,  presentation 
layer,  and  the  application  layer  are  combined  in  several  different  ways 
to  form  one  or  more  high-level  protocol  layers  not  discussed  here.  This 
is  done  depending  on  the  individual  system  requirements. 

Context  Diagram.  The  context  data  flow  diagram  shows  the  system 
boundary  and  interface  with  the  user.  From  Figure  4,  page  41,  it  can  be 
seen  that  the  network  operating  system  must  include  everything  between 
the  user  input  from  a  keyboard  that  is  connected  to  a  computer  in  the 
network,  to  the  response  that  the  user  receives  at  his  display.  Thus 
the  Network  Operating  System  includes  all  the  computer  operating  systems 
in  the  network  as  well  as  all  interface  software  and  hardware  required 
to  implement  the  network  functional  requirements.  To  initialize  the 
network,  a  configuration  bootstrap  process  is  also  required.  Table  4 
shows  the  layers  of  protocol  that  are  defined  in  the  set  of  DFDs  that 
follow.  Table  5  describes  the  process  hierarchy  for  the  first  set  of 
DFDs,  the  Network  Operating  System. 
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guru  4  Context  Diagram  0  DI’D 


Table  4 

Protocol  Layers 


EWNET 


ISO  -  OSI 


NETWORK  OPERATING  SYSTEM  -  ARCHITECTURE  PROTOCOL 

. . — .  PRESENTATION  PROTOCOL 

-  SESSION  PROTOCOL 

ARCHITECTURE  PROTOCOL  (DECNET)  - - -  ARCHITECTURE  PROTOCOL 

-  PRESENTATION  PROTOCOL 

- -  SESSION  PROTOCOL 

TRANSPORT  PROTOCOL  (DECNET)  - - -  SESSION  PROTOCOL 

-  TRANSPORT  PROTOCOL 

NETWORK  PROTOCOL  -  NETWORK  PROTOCOL 

DATA  LINK  PROTOCOL  (HDLC)  - - -  DATA  LINK  PROTOCOL 

PHYSICAL  PROTOCOL  (RS-232-C)  -  PHYSICAL  PROTOCOL 


Table  5-— Network  Operating  System  Process  Hierarchy 
1.0  Execute  EWNET  Protocol  at  Primary  Node 

1.1  Determine  Command  Type 

1.2  Execute  Help  Commands 

1.2.1  Decode  Help  Command 

1.2.2  Provide  General  Network  Info 

1.2.3  Provide  Procedure  for  Transferring  Files 

1.2.4  Provide  List  of  Active  Hosts  and  Devices 

1.2.5  Provide  Network  Startup  Procedures 

1.2.6  Code  Help  Responses 

1.3  Execute  Architecture  Level  Protocol 

1.4  Execute  Transport  Level  Protocol 

1.5  Execute  Network  Level  Protocol 

1.6  Execute  Link  Level  Protocol 

1.7  Execute  Physical  Level  Protocol 
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1.8  Decode  Protocol  Responses 


2.0  Execute  EWNET  Protocol  at  Secondary  Node 

System  Diagram.  The  system  diagram  translates  the  key  functional 
requirements  into  the  software  requirements  for  the  network  operating 
system  as  shown  in  Figures  5  and  6,  pages  44  and  45.  First*  the  user 
command  must  be  examined  to  determine  whether  it  is  a  help  command* 
network  command*  or  local  command  (1.1).  If  it  is  a  help  command*  then 
the  appropriate  help  information  must  be  output  to  the  user.  Depending 
upon  the  Type  of  help  command,  this  process  may  require  access  to  the 
Dialogue  Process  Table  (1.2). 

If  the  incoming  command  is  a  network  command,  then  send  it  to  the 
correct  protocol  level  to  be  implemented.  If  the  command  was  to 
transfer  a  file,  then  the  Architecture  Level  Protocol  will  execute  the 
command  (1.3).  Else,  if  the  command  is  to  start  or  stop  the  network 
then  the  Transport  Level  Protocol  will  execute  the  command  (1.4).  Once 
the  Architecture  Level  Protocol  has  been  implemented  for  a  file  access 
or  transfer  then  the  file  plus  the  Architecture  Protocol  Header  will  be 
sent  to  the  Transport  Level  Protocol  (1.4).  The  Transport  Protocol  will 
determine  if  the  file  transfer  or  initialization  request  is  for  a 
satellite  node  or  a  remote  node.  If  the  data  is  to  go  to  a  remote  node 
then  the  Transport  Protocol  Header  is  added  to  the  packet  and  it  is  sent 
to  the  Network  Level  Protocol  for  processing  (1.5).  The  Network  Level 
Protocol  adds  routing  information  headers  and  sends  it  to  the  Data  Link 
Level  Protocol  (1.6).  Also,  if  the  data  to  the  Transport  Level  Protocol 


Figure  5  Ewnet  Overview  (Network  Operating  System)  »l'l)  (O.u) 
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Figure  6  Execute  Kwnet  Protocol  at  Primary  Node  (ll  DF'I) 


is  to  be  sent  to  a  satellite  node  then  send  the  data  with  the  Transport 
Level  Protocol  Header  directly  to  the  Data  Link  Level  Protocol  (1.6). 
The  Data  Link  Level  Protocol  then  adds  its  own  header  and  sends  the 
entire  packet  to  the  Physical  Level  Protocol  (1.7),  which  transmits  the 
bit  stream.  Finally,  the  response  that  has  been  outputed  from  one  of 
the  three  processes  must  be  transmitted  back  to  the  user  as  the  network 
response  (1.8). 

If  the  user  command  was  a  local  command,  then  the  command  must  be 
routed  internally  to  perform  the  required  function.  In  all  processes 
listed  in  Figure  6,  page  45,  there  is  the  possibility  for  errors  to 
develop,  and  thus,  error  messages  must  be  generated  in  place  of  the 
expected  result. 

Help  User  Requirements.  The  user  help  process  may  be  specified 
further  by  the  lower- level  DFD  shown  in  Figure  7,  page  47.  The 
transmitted  help  request  must  be  classified  as  either  a  general 
information  request,  a  file  transfer  information  request,  a  list  of  the 
active  host  and  device  names,  or  a  protocol  start  information  request 
(1.2.1).  If  it  is  a  general  information  request,  then  a  menu  selection 
consisting  of  the  available  commands  and  their  formats  must  be  output 
along  with  the  formates  for  the  more  specific  help  requests  (1.2.2).  If 
the  transmitted  help  request  is  a  file  transfer  information  request, 
then  format  for  the  transfer  file  commands  must  be  output  (1.2.3).  If 
the  transmitted  help  request  is  a  list  of  the  active  hosts  and  device 
names  request,  then  this  list  must  be  output  by  accessing  the  Dialogue 
Process  Table  (1.2.4).  If  the  transmitted  help  request  is  a  protocol 
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gure  7  Execute  Help  Commands  (1.2)  DEI) 


start  information  requests  then  the  commands  necessary  to  start*  stop* 
and  abort  the  session  must  be  output  (1.2.5).  Finally,  all  help 
responses  are  output  to  the  user  as  a  help  response  (1.2.6). 

Architecture  Level  Protocol  Requirements.  The  previous  protocol 
requirements  were  specified  to  implement  the  applications  of  obtaining 
user  help  information  and  identifing  network  commands.  The  identifing 
of  the  network  commands  process  relies  upon  an  architecture  file 
transfer  mechanism  which  was  treated  as  a  primitive  by  this  process.  If 
the  DFD  partitioning  process  had  been  followed  as  specified  by  DeMarco, 
then  the  partitioning  of  the  file  transfer  mechanism  would  have  been 
duplicated  several  times.  However,  by  defining  the  file  transfer 
mechanisms  as  primitives  that  are  used  by  several  processes,  it  was 
possible  to  start  a  new  set  of  DFDs  for  this  mechanism  without  having  to 
duplicate  them  for  each  process.  Table  6  shows  the  overall  process 
hierarchy  for  the  Architecture  Level  Protocol  DFDs.  In  the  interest  of 
conservation  of  material,  the  detailed  DFDs  for  the  Architecture  Level 
are  not  included  in  the  text,  but  are  included  in  Appendix  C,  as  are  all 
upper  and  lower- level  DFDs  for  the  entire  software  specification. 


Table  6 - Architecture  Level  Protocol  Process  Hierarchy 

1.0  Execute  Architecture  Protocol  at  Primary  Node 

1.1  Decode  Architecture  Packets 

1.2  Decode  Status  Packets 
1.2.1  Check  for  Errors 
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1.2.2  Decode  MACCODE  Field 

1.2.3  Decode  Unsupported  MICCODE  Field 

1.2.4  Decode  Pending  MICCODE  Field 

1.2.5  Decode  Format  MICCODE  Field 

1.2.6  Decode  File  MICCODE  Field 

1.2.7  Decode  Sync  MICCODE  Field 

1.2.8  Decode  Successful  MICCODE  Field 

1.3  Generate  Control  Packets 

1.3.1  Decode  Control  Type 

1.3.2  Generate  Control  Connect  Packet 

1.3.3  Generate  Control  Seq-Get  Packet 

1.3.4  Generate  Control  Seq-Put  Packet 

1.3.5  Generate  Control  Key-Get  Packet 

1.3.6  Generate  Control  Key-Put  Packet 

1.3.7  Generate  Control  Add-Get  Packet 

1.3.8  Generate  Conti.il  Add-Put  Packet 

1.3.9  Code  Get  Fields 

1.3.10  Code  Put  fields 

1.3.11  Code  Control  Fields 

1.4  Execute  Startup  Packets 

1.4.1  Generate  Configuration  Packet 

1.4.2  Check  for  Configuration  Errors 

1.4.3  Decode  Configuration  Fields 

1.4.4  Generate  Attributes/Access  Packet 

1.4.5  Generate  Access/Erase/Rename  Packet 
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1.4.6  Generate  Access/ECF/SCF  Packet 

1.4.7  Generate  Attributes  Packet 

1.4.8  Check  for  Acknowledge  Errors 

1.4.9  Check  for  Attributes  Errors 

1.4.10  Check  for  Access  Errors 

1.4.11  Decode  Attributes  Fields 

1.4.12  Code  Setup  Errors 

1.4.13  Code  Setup  Packets 

1.5  Execute  ACC/ACK  Packets 

1.5.1  Generate  Access  Packet 

1.5.2  Decode  Access  Fields 

1.5.3  Generate  Access  Complete  Packet 

1.5.4  Generate  Acknowledge  Packet 

1.5.5  Check  for  Access  Complete  Errors 

1.5.6  Decode  CMPFUNC  Fields 

1.5.7  Generate  ATTRIB/ACK  Packet 

1.6  Execute  Control  Packets 

1.6.1  Decode  Control  Packet 

1.6.2  Decode  Connect  Fields 

1.6.3  Decode  Get  Fields 

1.6.4  Decode  Put  Fields 

1.7  Execute  Continue  Packets 

1.7.1  Decide  on  Next  Action 

1.7.2  Decide  on  Required  Action 


1.7.3  Generate  Continue  Abort  Packet 

1.7.4  Generate  Continue  Skip  Packet 

1.7.5  Generate  Continue  Only  Packet 

1.7.6  Code  Continue  Packets 

1.7.7  Generate  Data  Packet 

1.7.8  Code  Continue  Errors 

1.8  Code  Architecture  Packets 

1.8.1  Start/Stop  Timer 

1.8.2  Code  Working  Packets 

1.8.3  Generate  Status  Packets 

1.8.4  Terminate  Logical  Link 

1.8.5  Terminate  Data  Stream 

1.8.6  Code  File  Packets 

1.9  Check  for  Continue  Error 

2.0  Execute  Architecture  Protocol  at  Secondary  Node 

The  Architecture  Layer  provides  the  network  functions  for  the  user 
layer.  Modules  in  this  layer  include  network  remote  file  access 
modules*  a  remote  file  transfer  utility*  and  a  remote  system  loader 
module. 

The  use  of  the  network  remote  file  access  modules  and  the  remote 
file  transfer  utility  are  limited  to  the  following  type  of  files: 


1.  Sequential  -  Each  record's  position  depends  on  the  position 


of  the  previous  record.  Records  may  not  be  processed  in  any  other 
order  (Ref.  13:298). 

2.  Relative  -  Each  record  in  the  file  has  a  unique  identifying 
number,  its  record  number.  Records  may  be  accessed  randomly  by 
specifying  their  record  number  in  a  control  message  (Ref. 
13:298-299). 

3.  Direct/Indexed  -  These  files  have  records  organized 
according  to  some  classification  method,  usually  an  access  key. 
Within  a  particular  key.  the  records  are  assumed  to  be  sequential 
(Ref.  13:299). 

The  reason  for  this  is  because  it  was  felt  that  these  three  types 
of  files  were  the  types  projected  to  be  most  prevalent  on  the  network. 
Figure  8,  page  53,  is  the  overview  DFD  for  the  Architecture  Level 
Protocol.  Obviously,  the  most  important  function  of  the  Architecture 
Protocol  is  to  transfer  data  to  and  from  I/O  devices  and  mass  storage 
files  independent  of  the  I/O  structure  of  the  system  being  accessed. 
This  implys  that  the  protocol  must  be  transparent  to  the  files  being 
transferred.  From  the  network,  it  must  appear  as  if  the  EWNET  systems 
support  the  Architecture  Protocol  Messages  directly  within  their  file 
systems.  The  protocol  must  set  up  the  conversation  path  for  remote  file 
access,  transferring  data  over  the  link  and  terminating  the  logical 
link.  The  EWNET  processes  will  implement  the  Architecture  Protocol 
using  the  Transport/Network  Protocol  and  the  network  facilities  for  the 
creation  of  the  logical  link  and  for  flow  control.  Figure  9,  page  54, 
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is  the  upper-level  DFD  for  the  Architecture  Level  Protocol. 

Once  the  link  is  established  by  the  Transport  Level  Protocol,  the 
EWNET  processes  the  exchange  of  Architecture  Level  messages  to  set  up 
the  file  access.  These  initial  set  up  messages  include  configuration, 
file,  data  mode,  and  format  information.  A  data  stream  is  then  set  up 
to  transfer  data  over  the  link.  Data  may  be  sent  either  to  the 
accessing  node  as  in  a  retrieve  operation  or  from  it  as  in  a  store 
operation.  One  control  message  sets  up  the  data  stream  for  both 
sequential  and  random  access  file  transfer.  After  file  transfer  is 
accomplished,  additional  Architecture  Level  messages  terminate  the  data 
stream.  A  disconnect  request  terminates  the  logical  link.  Status 
messages  are  returned  if  there  are  errors  in  the  set  up  procedure,  file 
transfer,  or  termination. 

Transport  Level  Protocol  Requirements.  The  previous  protocol 
requirements  were  specified  to  implement  the  applications  of  file 
transfers  on  the  network.  These  file  transfer  processes  rely  upon  a 
Transport  Protocol  (transferring  mechanism)  which  was  treated  as  a 
primitive  by  these  processes.  Since  the  Transport  Protocol  is  a 
primitive  that  is  used  by  several  processes,  it  was  possible,  as  with 
the  architecture  protocol,  to  start  a  new  set  of  DFDs  for  this  mechanism 
without  having  to  duplicate  them  for  each  process.  Table  7  shows  the 
overall  process  hierarchy  for  this  set  of  DFDs.  As  with  the 
Architecture  Level  Protocol  DFDs,  only  the  upper- level  DFDs  will  be 
included  in  the  text  explaination  for  this  protocol. 
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1.0  Execute  Transport  Protocol  at  Primary  Node 

1.1  Decode  Route  Header 

1.1.1  Decode  RTHDR  Field 

1.1.2  Decode  MSGFLG  Field 

1.1.3  Generate  First  Disconnect  Confirm  Packet 

1.1.4  Examine  Logical-Link  Database 

1.1.5  Pass  to  Satellite 

1.2  Decode  Packet  Type 

1.3  Execute  Incoming  Dialogue  Message 

1.3.1  Execute  Dialogue  Segment 

1.3. 1.1  Decode  Dialogue  Message 

1.3. 1.2  Examine  Adjacent  Node  Parameter  and  Decode 

1.3.1 .3  Break  Dialogue  Data  into  Segments 

1.3. 1.4  Examine  Data  Flow  Control  Parameters 

1.3. 1.5  Piggyback  Data  Acknowledge 

1.3.1  6  Assign  Segment  Number  Mod  4096 

1.3. 1.7  Load  and  Delete  Data  Memory 

1.3. 1.8  Check  Data  Retransmit 

1.3. 1.9  Code  Data  and  I/L  Packets 

1.3.2  Execute  I/L  Packet 

1.3. 2.1  Examine  Interrupt  Flow  Control  Parameters 

1.3. 2. 2  Generate  Interrupt -Link  Services  Packet 

1.3. 2. 3  Piggyback  I/L  Acknowledge 

1.3. 2. 4  Code  I/L  Packet 
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1.3. 2. 5  Generate  Data-Link  Services  Packet 

1.3. 2. 6  Assign  Packet  Number  Mod  4096 

1.3. 2. 7  Load  and  Delete  I/L  Memory 

1.4  Execute  Data  Packet 

1.4.1  Determine  Data  Packet  Type 

1.4.2  Decode  Data  ACKNTJM  Field 

1.4.3  Decode  Data  Segment  Number 

1.4.4  Decode  I/L  Segment  Number 

1.4.5  Decode  I/L  ACKNUMI  Field 

1.4.6  Generate  Data  Acknowledge  Packet 

1.4.7  Generate  Data  Negative  Acknowledge  Packet 

1.4.8  Load  Receive  Buffer  until  Full  or  LS 

1.4.9  Generate  I/L  Negative  Acknowledge  Packet 

1.4.10  Generate  I/L  Acknowledge  Packet 

1.4.11  Decode  Valid  I/L  Packet 

1.4.12  Code  Acknowledge  Packets 

1.4.13  Code  Data  Packets 

1.4.14  Decode  Link  Services  Packet 

1.5  Execute  Startup  Packet 

1.5.1  Transition  Link  to  On-Line  Mode 

1.5.2  Decode  Functions  Field 

1.5.3  Decode  Initialization  Packet 

1.5.4  Generate  Node  Initialization  Packet  Verify 

1.5.5  Decode  Remaining  Fields 
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1.5.6  Generate  Node  Verification  Packet 

1.5.7  Generate  Node  Initialization  Packet  Verify 

1.5.8  Decode  Password 

1.5.9  Code  Initialization  Packets 

1.6  Execute  Control  Packet 

1.6.1  Execute  Connect  Packet 

1.6. 1.1  Generate  Connect  Initiate  Packet 

1.6. 1.2  Decode  Control  Packet 

1.6. 1.3  Decode  Connect  Initiate  Packet 

1.6. 1.4  Dialogue  Process  External  End 

1.6. 1.5  Decode  Connect  Confirm  Packet 

1.6. 1.6  Generate  Connect  Confirm  Packet 

1.6. 1.7  Generate  Disconnect  Initiate  Packet 

1.6. 1.8  Code  Control  Packet 

1.6.2  Execute  Disconnect  Packet 

1.6. 2.1  Decode  Disconnect  Confirm  Packet 

1.6. 2. 2  Decode  Disconnect  Initiate  Packet 

1.6. 2. 3  Dialogue  Process  End 

1.6. 2. 4  Generate  Disconnect  Confirm  Packet 

1.7  Execute  Acknowledge  Packet 

1.7.1  Determine  Acknowledge  Type 

1.7.2  Decode  Data  ACK  Packet 

1.7.3  Decode  I/L  -  ACK  Packet 
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1.8  Execute  Outgoing  Transport  Packets 

1.8.1  Examine  DSTADDR  Field 


1.8.2  Add  RTHDR  Field 

1.8.3  Is  Routing  Necessary  and  Present 

1.8.4  Pass  to  Correct  Adjacent  Node 

1.9  Code  Outgoing  Dialogue  Message 

1.10  Send  to  Network  Protocol 

4.0  Execute  Transport  Protocol  at  Secondary  Node 

The  overview  DFD  for  the  Transport  Layer  is  shown  in  Figure  10, 
page  60.  Obviously,  the  most  important  function  of  this  protocol  is  to 
transmit  data  from  the  source  host  to  the  destination  host.  To 
accomplish  this  function  the  Transport  Protocol  must  retain  primary 
responsibility  for: 

1.  Establishing,  maintaining,  and  destroying  communication 
links  between  different  user  and  network  application  program 
modules . 

2.  Performing  initialization  between  adjacent  nodes. 

3.  Acknowledgement  of  all  messages. 

4.  Detecting  node  and  line  failures. 

In  addition,  the  Transport  Protocol  will  provide  the  facility  for 
two  dialogue  processes  (typically,  user-written  or  network  application 
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modules  residing  at  different  nodes)  to  exchange  information  regardless 
$  of  their  physical  location  within  a  network.  This  facility  is  referred 

to  as  Logical  Link  Service  (Ref.  12.*  127). 

Logical  Link  Service  allows  a  dialogue  process  to  establish  a 
connection  (called  a  logical  link)  to  another  dialogue  process.  Once 
the  logical  link  is  established,  each  dialogue  process  may  send  data  to 
the  other  dialogue  process  via  the  logical  link.  When  the  dialogue  is 
complete,  either  dialogue  process  may  request  that  the  logical  link  be 
disconnected.  A  logical  link  provides  both  guaranteed  delivery  (that 
is,  delivery  of  information  to  an  area  of  storage  accessable  to  the 
destination  process)  and  sequentiality. 

Other  network  management  activities  performed  by  the  Transport 
Level  Protocol  are  data  flow  control,  node  initialization,  destination 
node  and  process  identification,  and  link  failure  handling. 

To  support  the  above  functions  the  Transport  Protocol  must  have  two 
types  of  messages  that  it  uses.  These  are  Data  Messages  and  Control 
Messages.  Data  Messages  are  also  of  two  types:  normal  data  messages 

and  interrupt  messages.  Normal  data  messages  can  be  either  an  entire 
message  or  a  message  segment.  Interrupt  messages  carry  small  amounts  of 
information  (high-priority  information  such  as  an  alarm  condition). 

Control  Messages  pass  information  between  the  Transport  modules. 
These  messages  are  used  for  the  following  purposes: 

1.  Starting  up  and  initializing  nodes. 
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2.  Testing 


3.  Establishing,  maintaining,  and  terminating  logical  link 
operation,  and 

4.  Controlling  the  flow  of  data  and  interrupt  messages  on  a 
logical  link. 

The  reason  for  the  interrupt  data  commands  is  to  allow  long 
transfering  files  to  be  interrupted  for  the  transmission  of  the  network 
control  commands.  If  this  were  not  done,  a  long  file  transfer  could 
easily  degrade  the  response  time  of  a  network  command  to  an  unacceptable 
level . 


This  concept  of  interrupting  file  transfers  requires  that  the 
transmission  medium  be  shared.  Time  Division  Multiplexing  (TDM)  or 
Frequency  Division  Multiplexing  (FDM)  could  provide  multiple  paths 
between  any  two  hosts  as  could  many  topologies  (Ref.  12).  However, 
since  the  throughput  requirement  might  possibly  grow  greater  than  the 
channel  capacity  between  nodes  on  EWNET,  FDM  was  thought  to  be  the  best 
way  to  meet  present  and  future  response  time  requirements.  Therefore, 
it  was  decided  that,  since  a  large  bandwidth  transmission  medium  will  be 

e 
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used  on  EWNET  and  an  initial  high  throughput  would  be  required,  a 
Frequency  Division  Multiplexed  Packet  Switched  Protocol  would  be 
appropriate  for  the  Transport  Level  Protocol.  Due  to  the  constraint  of 
developing  a  network  for  the  Engineering  Branch  that  would  meet  all 
internal  standardization  requirements  and  be  an  off-the-shelf  item,  the 


Digital  Equipment  Corporation’s  DECNET  Protocol  was  chosen  for  EWNET. 
The  DECNET  Digital  Network  Architecture  (DNA)  model  and  its  application 
to  the  EWNET  will  be  discussed  in  Chapter  4  of  this  thesis.  Figure  11, 
page  64,  is  the  Transport  Level  Protocol  high-level  DFD  for  the  EWNET. 

The  Transport  Level  Protocol  is  responsible  for  establishing  and 
destroying  a  logical  link  between  dialogue  processes.  This  is 
accomplished  via  a  set  of  control  messages  sent  back  and  forth  between 
Transport  modules.  Once  a  logical  link  has  been  established,  data  may 
be  exchanged  over  the  link.  Information  sent  over  the  link  can  be:  (1) 
normal  data  —  that  is,  data  segments  or  messages  or  (2)  interrupt  data. 
Dialogue  messages  are  usually  sent  as  normal  data  segments  over  the 
link. 

Unless  the  message  to  be  sent  is  small  enough  to  be  transmitted 
through  the  network  intact,  the  Transport  Protocol  will  break  up  the 
message  into  segments  and  transmit  each  segment  individually.  To  ensure 
proper  data  sequentiality  and  delivery,  each  Transport  module  employs  a 
segment  acknowledgement  scheme.  This  scheme  keeps  track  of  data 
segments  sent  and  ascertains  whether  or  not  retransmission  is  necessary. 
At  any  time  during  a  dialogue  exchange,  the  Transport  Protocol  will 
allow  either  process/party  to  abort  or  terminate  the  conversation.  When 
the  Transport  Protocol  has  been  properly  notified  to  do  so,  it  will 
disconnect  the  logical  link. 

There  are  two  data  streams  on  a  logical  link.  One  stream  contains 
interrupt  (for  user  high-priority  information)  and  link  service  messages 


(for  Transport  flow  control);  the  other  contains  normal  data  messages. 
Each  stream  may  be  considered  a  subchannel  on  the  logical  link.  On  the 
interrupt/ link  service  subchannel,  all  messages  are  single  Transport 
segments.  On  the  data  subchannel,  however,  data  messages  are  usually 
broken  up  into  segments.  Transport  segment  acknowledgement  is  performed 
independently  for  each  subchannel. 

When  normal  data  (dialogue)  messages  are  broken  up  into  segments, 
the  transmit  segment  size  parameter  determines  the  size  of  these 
segments.  The  value  of  the  parameter  is  specified  when  the  logical  link 
is  established.  In  addition,  transmitter  and  receiver  subchannels  must 
be  synchronized  for  all  data  message  transmission.  This  is  accomplished 
at  the  transmitter  using  the  interrupt/link  service  subchannel  transmit 
number  and  the  data  subchannel  transmit  number  and  at  the  receiver  using 
corresponding  receive  numbers.  When  a  logical  link  connection  is 
established  between  two  dialogue  processes,  these  numbers  are  set  to  1. 
As  Transport  segments  are  transmitted  and  acknowledged  over  the  logical 
link,  the  appropriate  numbers  are  incremented. 

Operating  at  a  level  above  the  segment  acknowledgement  scheme  is 
the  flow  control  operation.  Its  purpose  is  to  determine  whether  there 
should  be  a  permanent  shift  from  the  transmitter  to  the  receiver  in  the 
buffering  of  information.  Four  parameters  are  associated  with  flow 
control:  a  data  flow  control  switch  ("open"  or  "closed");  an  interrupt 
request  count;  a  data  request  switch  ("segment”);  and  a  data  request 
count.  The  receiver  may  control  data  flow  by  sending  a  link  service 
message  that  sets  appropriate  parameters.  The  receiver  can  request 


interrupt  mes sages •  stop  data  segment  flow,  allow  data  segment  flow,  and 
request  data  by  means  of  the  segment  request  count.  The  transmitter 
responds  appropriately  to  the  link  service  message  of  the  receiver. 
When  the  transmitter  has  data  to  send  (either  normal  data  or  interrupt), 
it  examines  the  appropriate  flow  control  parameters  and  request  count 
before  sending  the  data.  The  receiver  may  reject  segments  for  which  it 
does  not  have  buffer  space  available  by  sending  a  negative 
acknowledgement . 

Network.  Level  Protocol  Requirements.  As  with  the  Transport 
Protocol,  the  Network  Level  Protocol  is  used  by  several  processes  and  is 
treated  as  a  primitive  by  all  other  protocol  levels.  Table  8  shows  the 
overall  process  hierarchy  for  this  set  of  DFDs. 


Table  8 - Network  Level  Protocol  Process  Hierarchy 

2.0  Execute  Network  Protocol  at  Primary  Node 

2.1  Decode  message  type 

2.2  Check  R-Hop  Count  =  2 

2.3  Decode  Network  Header 

2.4  Increment  Hop 

2.5  Update  Routing  Table  If  New 

2.6  Determine  Least  Cost  Link 

2.7  Add  Network  Header 

2.8  Send  Old  Values  Out  Over  New  Initialized  Line 

2.9  Check  N-Hop  Count  =  2 
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2.10  Update  Network  Header 

2.11  Every  Timer  Interval  Update  Adjacent  Line 

2.12  Issue  Correct  Link  Cost  Over  All  Links 

2.13  Send  Packet  Over  Correct  Line(s) 

3.0  Execute  Network  Protocol  at  Secondary  Node 

The  overview  DFD  for  the  network  layer  is  shown  in  Figure  10.  page 
60.  The  most  important  function  of  this  protocol  is  to  implement  what 
is  termed  in  the  communication  field  a  Datagram  Service  (Ref.  12:60). 
A  Datagram  Service  delivers  packets  on  a  "best  effort"  basis.  That  is, 
the  Network  Protocol  makes  no  absolute  guarantees  against  packets  being 
lost,  duplicated,  or  delivered  out  of  order.  Rather,  higher  layers  of 
the  EWNET  Protocol  structure  provide  such  guarantees  (Transport  Level 
Protocol).  The  Network  Protocol  selects  routes  based  on  network 
topology  and  operator-assigned  line  costs.  The  Network  Protocol 
automatically  adapts  to  changes  in  the  network  topology,  for  example,  by 
finding  an  alternate  path  if  a  line  or  node  fails.  This  protocol  does 
not  adapt  to  traffic  loading:  the  amount  of  traffic  on  a  channel  does 
not  affect  the  Network  Protocol's  routing  algorithms.  Figure  12,  page 
68,  is  the  Network  Level  Protocol  DFD  for  the  EWNET. 

The  Network  Level  Protocol  is  responsible  for  providing  the 
following  functions: 

1.  Determines  packet  paths.  A  path  is  the  sequence  of 
connected  nodes  between  a  source  node  and  a  destination  node.  If 
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gure  12  Execute  Network  Protocol  at  Primary  Node  (2)  DEI) 


♦ 
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more  than  one  path  exists  for  a  packet,  the  Network  Protocol 
determines  the  best  path. 


2.  Forward  packets.  If  a  packet  is  addressed  to  the  local 
node,  the  protocol  forwards  it  up  to  the  Transport  Level  Protocol 
for  disposition.  If  a  packet  is  addressed  to  a  remote  node,  the 
protocol  forwards  it  on  to  the  next  line  in  the  path. 

3.  Manages  the  characteristics  of  packet  paths.  If  a  line  or 
node  fails  on  a  path,  the  Network  Protocol  finds  an  alternate  path, 
if  one  exists. 

4.  Periodically  updates  other  Network  Level  modules.  Other 
Network  Level  modules  are  periodically  updated  so  that  all  nodes  in 
the  network  are  aware  of  any  routing  change  (such  as  a  line  down  or 
a  node  coming  up). 

5.  Limits  the  number  of  nodes  a  packet  can  visit.  This 
prevents  old  packets  from  cluttering  the  network. 

There  are  two  types  of  Network  Protocol  messages:  data  messages 
and  control  messages.  Data  messages  carry  data  from  the  Transport  Level 
Protocol.  The  Network  Protocol  adds  a  packet  route  header  to  the 
Transport  Level  messages.  Control  messages  exchange  information  between 
Network  Protocol  modules  in  adjacent  nodes  to  maintain  the  routing 
tables . 


69 


One  of  the  constraints  on  the  EWNET 


design  was  that  it  start  with  a  minimal  set  of  capabilities  while 
retaining  the  flexiability  to  be  expanded  if  future  requirements  demand 
such  an  expansion.  Therefore,  the  routing  algorithm  initially 
implemented  was  relatively  simple,  while  retaining  the  capability  to  be 
expanded  if  the  need  arises.  The  routing  algorithm  consist  of  seven 
processes  that  must  be  performed: 

1.  Decision.  The  decision  process  selects  routes  to  each 
destination  in  the  network.  It  consist  of  a  connectivity  algorithm 
that  maintains  path  lengths,  and  a  traffic  assignment  algorithm  that 
maintains  path  costs.  Path  length  is  the  sum  of  the  hops  along  a 
path  between  two  nodes.  Line  cost  is  a  positive  integer  value 
associated  with  using  a  line,  and  path  cost  is  the  sum  of  the  line 
costs  along  a  path  between  two  nodes.  When  a  routing  node  receives 
a  Routing  Packet,  the  routing  node  executes  tue  two  decision 
algorithms.  Executing  both  algorithms  is  required  since  a  packet 
might  have  a  choice  of  two  paths,  both  having  equal  cost  but  less 
hops  required,  or  having  equal  hops  required  but  less  cost  per  line. 
This  execution  results  in  updating  the  databases  used  to  determine 
packet  routes. 

2.  Update.  The  update  process  constructs  and  propagates 
Routing  Packets.  The  update  process  sends  Routing  Packets  to 
adjacent  nodes  as  required  by  the  decision  process  and  periodically 
to  ensure  the  integrity  of  the  routing  databases. 


3.  Forwarding.  The  forwarding  process  supplies  and  manages 
the  buffers  necessary  to  support  packet  route-through  to  all 
destinations . 

4.  Select.  The  select  process  performs  a  table  look-up  to 
select  the  output  line  for  the  packet.  If  a  destination  is 
unreachable,  this  process  discards  the  packet. 

5.  Receive.  The  receive  process  inspects  a  packet's  route 
header,  dispatching  the  packet  to  the  appropriate  Network  Level  or 
Transport  Level  module. 

6.  Congestion  Control.  This  implementation  of  the  EWNET 
Network  Level  Protocol  does  not  perform  any  congestion  control 
functions  upon  the  network. 

7.  Packet  Lifetime  Control.  A  loop  detector  prevents 
excessive  packet  looping  by  discarding  packets  that  have  visited  too 
many  nodes . 

As  the  topology  of  EWNET  evolves  this  simple  adaptive  routing 
algorithm  will  require  updating  to  a  more  complex  distributed  adaptive 
routing  algorithm  (Ref.  11:235-237). 

Data  Link  Level  Protocol  Requirements.  This  protocol  level  is 
modeled  after  the  High  Level  Data  Link  Control  (HDLC)  (Ref. 
12:208-232).  The  overview  DFD  for  this  protocol  level  is  shown  in 
Figure  13,  page  72.  Also,  Table  9  shows  the  process  hierarchy  for  this 
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set  of  DFDs 


1.2  Frame  Secondary  Incoming  Packets 

1.2.1  Check  Header  Length 

1.2.2  Check  BLKCK1 

1.2.3  Check  Data  Length  (Count) 

1.2.4  Check  BLKCK2 

1.2.5  Check  ENQ  Header  Length 

1.2.6  Check  BLKCK3 

1.2.7  Generate  CRC  Remainder 

1.2.8  Check  Select  Bit 


1.3  Execute  Incoming  Control  Packet 

1.3.1  Decode  ENQ  Packet 

1.3.2  Set  NAK  Transmit  Flag 

1.3.3  Set  Negative  Acknowledge  Flag,  Reset  Timer 

1.3.4  Check  STRT  Select  Bit 
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1.3.5  Check  STACK  Select  Bit 

1.3.6  Check  NUM  Field  to  R 

1.3.7  Set  Acknowledge  Flag,  Reset  Timer 

1.3.8  Count  Errors  (NAK) 

1.4  Execute  Outgoing  Control  Packet 

1.4.1  N=N+1 ,  Reset  Timer 

1.4.2  Generate  Negative  Acknowledge  Packet 

1.4.3  Generate  Start  Packet 

1.4.4  Generate  Start  Acknowledge  Packet 

1.4.5  Generate  Acknowledge  Packet 

1.4.6  Generate  REP  Packet 

1.4.7  Clear  Negative  Acknowledge  Flag 

1.4.8  If  Initialization,  then  Pad  Packet 

1.4.9  Clear  Acknowledge  Flag 

1.4.10  Clear  SREP  Flag 

1.5  Execute  Data  Packet 

1.5.1  Process  NUM  Field 

1.5.2  Process  RESP  Field 

1.6  Execute  Maintenance  Packet 

1.6.1  Generate  Maintenance  Mode  Packets 

1.6.2  Generate  Maintenance  Packet 

1.7  Frame  Primary  Information  Packets 

1.7.1  Add  4  Sync  Bytes  to  Packet  if  QSYNC 

1.7.2  Count  Data  Field  ADD  BLKCK2  /  Count 
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1.7.3  Add  Remaining  Header  Fields 

1.7.4  Set  OSYNC  Bit 


1.7.3  Count  Header  Field  and  Add  BLKCK1 

1.7.6  Piggyback  Acknowledge  Received:  Set  RESP 

1.7.7  Check  Modulo  256 

1.7.8  Increment  Packet  Count 

1.7.9  Check  Retransmit 

1.7.10  Add  4  Sync  Bytes  to  Data  Packet  if  QSYNC  /  INIT. 

1.7.11  Load  and  Delete  Memory 

1.8  Start  Reply  Timer 

1.8.1  If  STRT,  STACK,  or  Data  Packet  then  Start  Timer 

1.8.2  Reset  Timer 

1.8.3  Count  Errors  (Time) 

1.8.4  Identify  Timeout  Packet 

2.0  Transmit  Bit  Streams 

3.0  Execute  HDLC  Protocol  at  Secondary  Node 

This  layer  of  the  EWNET  Protocol  Structure  controls  the  operation 
of  the  physical  link,  maintaining  the  integrity  and  sequentiality  of 
data  tr^smitted  over  a  communication  channel.  This  Data  Link  Protocol 
is  a  byte-oriented  link  control  procedure  that  operates  in  full-duplex 
synchronous  mode  and  supports  point-to-point  communications.  This 
protocol  is  concerned  with  the  logical  transmission  of  data  grouped  into 
physical  blocks  known  as  data  packets.  The  primary  function  of  the 
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protocol  being  the  exchange  of  these  data  packets  while  ensuring  their 
correctness.  Each  data  packet  is  assigned  a  number  to  ensure  proper 
packet  sequencing  at  the  receiver.  The  numbering  begins  with  number  one 
after  initialization  and  is  incremented  by  one  (modulo  256)  for  each 
subsequent  data  packet.  The  receiver  acknowledges  the  correct  receipt 
of  data  packets  by  returning  the  packet  number  as  a  response. 
Acknowledgement  of  data  packet  n  implies  acknowledgement  of  all  data 
packets  sent  up  to  and  including  data  packet  n.  Additionally,  the  Data 
Link  Protocol  provides  an  envelop  in  which  maintenance  messages  can  be 
sent  for  down-line  loading,  up-line  dumping,  loopback  testing  and 
control  of  unattended  remote  systems.  The  protocol  uses  retransmission 
to  recover  from  errors.  The  error  recovery  mechanism  uses  timeouts  and 
control  packets  to  resynchronize  and  trigger  retransmission.  Figure  14, 
page  77,  is  the  Data  Link  Level  Protocol  high-level  DFD  for  EWNET, 
low-level  DFDs  are  supplied  in  Appendix  C. 

The  Data  Link  Protocol  uses  three  types  of  packets:  data  packets, 
control  packets,  and  maintenance  packets.  All  data  is  sent  over  the 
physical  link  in  numbered  data  packets.  Responses  and  control 
information  are  returned  within  unnumbered  control  packets.  In  the 
maintenance  mode,  the  protocol  provides  a  maintenance  packet  envelop  for 
boot  strapping,  dumping  and  link  testing.  The  initial  field  of  each 
packet  is  a  special  ASCII  character  (SOH,  ENQ,  or  DLE  respectively). 

The  Data  Link  Level  Protocol  consist  of  three  functional 
components:  Framing,  Link  Management,  and  Packet  Exchange. 
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glare  14  Execute  HDI.C  Protocol  at.  Primary  Node 


r 

Framing  is  the  process  of  locating  the  beginning  and  end  of  a 
packet  at  the  receiving  end  of  a  link  (Ref.  12:201-202).  It  requires 
synchronization:  locating  a  certain  bit,  byte  or  packet  and  then 
operating  at  the  same  rate  as  the  bit,  byte,  or  packet.  Framing  is 
achieved  when  data  is  synchronized  at  the  bit,  byte,  or  packet  levels 
(Ref.  12:330).  Bit  synchronization  is  done  by  the  modems  and 
interfaces  on  the  link.  Byte  synchronization  involves  locating  the 
proper  8-bit  window  in  the  bit  stream.  This  is  accomplished  by  a  sync 
character  search.  Packet  synchronization  is  achieved  by  searching  for 
one  of  the  three  special  starting  bytes  (SOH,  ENQ,  or  DLE) .  After 
achieving  byte  synchronization  the  packet  synchronization  is  maintained 
by  counting  out  the  fixed  length  headers,  and,  when  required,  the 
variable  length  data,  based  on  the  count  field  supplied  in  the  header. 

The  Link  Management  component  controls  the  transmission  and 
reception  on  links  connected  to  two  or  more  transmitters  and/or 
receivers  in  a  given  direction  (Ref.  12:122-129). 

The  Packet  Exchange  component  transfers  the  data  correctly  and  in 
sequence  over  the  link.  Once  framing  is  accomplished,  this  component 
operates  at  the  packet  l'jvel,  exchanging  data  and  control  packets. 

i 

The  Data  Link  Protocol  is  a  positive  acknowledgement  retransmission 
protocol.  For  each  data  packet  correctly  received  and  passed  to  the 
next  level,  a  positive  acknowledgement  is  returned  on  the  link, 
notifying  the  transmitter  of  the  correct  receipt  of  the  data  packet.  If 
a  data  packet  is  incorrectly  received,  the  data  is  not  passed  to  the 
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user  and  Che  packet  is  not  acknowledged.  Eventually*  the  packet  will  be 
retransmitted.  For  efficiency,  the  Data  Link  Protocol  may  transmit 
several  packets  (up  to  255)  before  requiring  the  acknowledgement  of  the 
first  one.  This  is  called  pipelining  (Ref.  11:153-157).  If  the  CRC 
block  check  reveals  a  transmission  error,  the  receiver  returns  a 
negative  acknowledgement. 

The  Data  Link  Protocol  provides  three  types  of  counters  for 
recording  and  evaluating  errors:  Threshold  counters.  Cumulative 
counters,  and  Background  counters.  Threshold  counters  are  used  to 
detect  persistent  error  conditions;  Cumulative  counters  record  overall 
error  statistics;  and  Background  counters  provide  a  base  on  which  to 
evaluate  performance.  To  determine  a  persistent  error,  the  protocol 
counts  consecutive  errors,  notifying  the  user  when  a  predefined 
threshold  value  is  reached. 

Physical  Level  Protocol  Requirements..  The  DECNET  does  not  require 
that  any  one  physical  level  protocol  be  used  (Ref.  13:300).  Thus, 
there  were,  only  two  requirements  for  the  physical  level  protocol.  It 
had  to  be  a  widely  recognized  standard  to  minimize  the  difficulty  in 
adding  new  hosts  to  EWNET  and  it  had  to  be  compatible  with  the 
transmission  medium  selected  and  the  distances  of  transmission  required. 
Thus,  if  these  requirements  could  be  met  then  the  Transmit  Bit  Streams 
(2.0)  process  in  the  Data  Link  Level  Protocol  (Figure  13,  page  72)  could 
be  performed. 
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Summary 

This  chapter  has  refined  the  hardware  specifications  and  addressed 
the  software  specifications  for  EWNET  in  detail.  The  software 
specification  was  lengthy  Sut.  because  of  the  partitioning  and  levels  of 
abstraction  made  possible  through  the  use  of  Structured  Analysis*  if  was 
easier  to  comprehend  than  would  otherwise  be  possible.  The  data 
dictionary  contains  the  explicit  information  on  these  specifications  and 
is  included  in  Appendix  C  along  with  the  high  and  low-level  data  flow 
diagrams.  These  requirements  formed  the  basic  foundation  for  the 
overall  structural  design  approach  taken  in  Chapter  IV  to  design  the 
EWNET. 


> 


The  previous  chapters  determined  the  user  functional  requirements 
and  translated  them  into  detailed  hardware  and  structured  software 
specifications.  In  this  chapter,  the  hardware  requirements 
specification  was  employed  along  with  supporting  background  information 
to  develop  the  hardware  design.  The  software  for  EWNET  was  also 
designed  by  selecting  the  specification  of  a  commerically  available 
network  design  (DECNET).  As  a  part  cf  the  software  and  hardware  design. 
Appendix  D  contains  a  complete  EWNET  Network  Profile  for  use  by  the 
Electronic  Warfare  Engineering  Branch  as  a  means  of  obtaining  the 
correct  commerically  available  network  configuration  to  meet  their 
present  and  future  needs.  This  chapter  also  presents  diagrams  that 
depict  the  exact  interaction  of  the  Host-to-Node  network  configuation 
selected  for  the  EWNET  design. 


Hardware  .Design 

Topology.  The  topology  shown  in  Figure  15,  page  82,  was  chosen  for 
EWNET  for  two  reasons.  First,  the  basic  loop  architecture  of  the  nodes 
allows  the  initial  routing  algorithm  to  be  "simple"  since  a  message  has 
only  two  possible  paths  to  its  destination  node.  This  gives  the 
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m 


capability,  as  identified  in  the  functional  requirements,  in  the  least 
amount  of  development  time;  thereby,  allowing  additional  time  to 
evaluate  and  develop  a  more  sophisticated  routing  algorithm  to  handle 
more  complex  future  topologies.  Second,  to  maintain  a  cost-effective 
initial  network,  the  loop  network  has  only  one  more  link  between  nodes 
than  a  minimum  spanning  tree,  since  deleting  one  of  the  links,  results 
in  a  linear  connection  of  the  node  computers.  This  linear  connected 
network  then  constitutes  a  minimum  spanning  tree  since  additional 
node-link  deletions  would  result  in  a  non-connected  network.  As  the 
topology  of  EWNET  expands  to  include  an  additional  node  computer,  it 
will  no  longer  be  possible  to  take  advantage  of  the  cost-effectiveness 
derived  from  the  minimum  spanning  tree  concept,  since  the  basic  loop 
architecture  will  be  replaced  by  a  topology  which  will  give  maximum 
reliability  and  response  time  to  the  network. 

The  star  topology  connecting  the  hosts  to  the  node  was  chosen  for 
several  reasons.  First,  it  minimizes  the  loop  topology  disadvantages  of 
increased  response  time  and  reduced  reliability  due  to  multiple  node 
computers  connected  in  a  single  loop.  Second,  the  topology  given  in 
Figure  15,  page  82,  takes  full  advantage  of  the  star  configuration  by 
grouping  around  the  same  node  those  host  that  will  interact  the  most 
with  each  other.  In  this  configuration,  much  of  the  traffic  need  only 
pass  through  its  entry  node  to  the  network.  This  decreases  the  average 
response  time  on  EWNET  and  decreases  the  amount  of  traffic  transmitted 
between  nodes.  However,  reliability  from  the  host's  perspective  is 
decreased  since  the  failure  of  a  node  can  cause  several  hosts  to  lose 
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access  to  the  network.  Also*  there  must  be  a  greater  transmission  rate 
between  nodes  than  that  between  the  hosts  and  the  nodes.  This  is  to 
keep  the  nodes  from  acting  as  bottlenecks  and  thereby  decreasing 
throughput  to  an  unacceptable  level.  Finally*  the  star  configuration 
allows  any  host  to  be  able  to  drop  out  of  the  network  without  adversely 
aftecting  the  performance  of  the  network.  This  meets  the  requirement* 
that  all  ISSes  must  be  able  to  operate  completely  independent  from  the 
network  without  affecting  the  network. 

Hosts.  Fourteen  hosts  were  chosen  for  the  initial  network 
configuration.  This  number  represents  those  EW  systems  within  the 
Electronic  Warfare  Engineering  Branch  Laboratory  which  will  require  the 
greatest  access  to  the  network  and  which  contain  the  most  sophisticated 
and  powerful  minicomputers.  The  following  list  of  Hosts  represents  a 
generous  cross-section  of  the  type  systems  which  will  require  access  to 
the  network  (present  and  future) . 

1.  F-15  Tactical  Electronic  Warfare  System  (TEWS)  =  Integrated 
ISS  System 

2.  EF-111A  =  Integrated  ISS  System 

3.  APR-38  =  Fire  control  ISS  System 

4.  Area  Reprogrammable  Capability  (ARC)  =  EW  system  emulation 
ISS  System 

5.  ALQ-131  -  Jammer  ISS  System 

6.  ALQ-155  =  Jammer  ISS  System 

7.  ALQ-119  =  Jammer  ISS  System 

8.  ALR-69  =  Radar  Warning  Receiver  (RWR)  ISS  System 

9.  EWOLS/ECSAS  =  Simulation  and  analysis  systems  respectively 
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10.  B-52  =  Tail  Warning  1SS  System 

11.  ALR-62  =  RWR  ISS  System 

12.  ALR-46  =  RWR  ISS  System 

13.  Flight  Line  Test  Sets  (FLTS)  =  FITS  ISS  System 

14.  ALQ-125  =  Electronic  Intelligence  Gathering  (ELINT)  ISS 
System 

Nodes .  Since  there  existed  no  requirement  to  be  able  to  internally 
modify  the  network  protocols  once  the  network  was  established,  and  due 
to  the  standardization  efforts  of  the  Electronic  Warfare  Engineering 
Branch  (Ref.  3).  it  was  decided  that  the  node  computers  used  within  the 
network  should  be  compatible  with  the  standardized  ISS  computer  and  at 
the  same  time  be  able  to  host  the  commercially  selected  software 
protocol  design.  This  resulted  in  the  selection  process  for  the  node 
computers  being  narrowed  down  to  the  Digital  Equipment  Corporation's 
PDP-11  family  of  computers.  There  still  remained  the  management 
requested  requirement  that,  if  possible,  the  organizational  Host 
Processor  (tJNIVAC-1108)  functions  and  the  Network  Routing  Node  functions 
be  performed  by  the  same  computer(s).  Therefore,  it  was  decided  that 
the  Network  Node  computers  could  easily  perform  the  existing 
organizational  Host  Processor  functions  if  the  node  computers  were  of 
sufficient  sophistication. 

The  Digital  Equipment  Corporation's  PDP-11/70  computer  was  selected 
for  the  EWNET  Node  computers.  It  is  of  sufficient  sophistication  to 
support  all  present  and  future  organizational  Host  Processor  functions 
(Ref.  14:261-305).  it  meets  all  Electronic  Warfare  Engineering  Branch 
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Laboratory  standardization  efforts  (Ref.  3),  and  it  supports  the  Phase 
III  routing  DECNET  software  (Ref.  15:67).  As  shown  in  Figure  16.  page 
87*  there  will  initially  be  three  PDP-11/70  node  computers.  The 
division  of  functions  for  these  computers  other  than  network  functions 
is  given  below: 

1.  First  Floor  Node  =  Host  all  off-line  ISS  backup  assemblers. 

2.  Second  Floor  Node  =  Host  all  common  ISS  software  tools  and 
common  databases  such  as  the  organizational  threat  database. 

3.  Third  Floor  Node  =  Host  all  off-line  ISS  (Flight  Test)  data 
reduction  programs. 

Transmission  Medium.  Due  to  the  security  and  EMI  requirements  for 
EWNET.  as  discussed  in  Chapter  3»  all  transmission  links  within  the 
network  will  use  fiber  optics.  The  optimum  transmission  rate  for  the 
network,  considering  the  throughput  and  response  time  requirements,  was 
1  mbps. 

Appendix  D  contains  further  details  concerning  the  hardware  design 
and  Figure  16.  page  87.  shows  the  total  hardware  design. 

Software  Design 

Introduction.  The  design  of  the  software  was  accomplished  through 
the  specification  of  a  commercially  available  network  design.  The 
Electronic  Warfare  Engineering  Branch  Management,  acting  in  behalf  of  a 


86 


Hodc  maker  lfc>R, 


Figure  16  Initial  Ewnel  Configuration 


then  non-existing  network  management  group*  specified  that  tne  EWNET 
design  must  be  obtained  from  an  existing*  contract  supportable* 
commercially  available  network  design  that  would  meet  all  internal 
standardization  efforts  and  be  as  compatible  as  possible  with  existing 
ISS  standard  computers.  Considering  these  requirements  the  Cigital 
Equipment  Corporation's  DECNET  product  was  selected  (Ref.  15:331-349). 

DECNET ■  DECNET  is  the  collective  name  for  the  set  of  software 
products  that  extend  various  Digital  Equipment  Corporation  operating 
systems  by  enabling  the  user  to  interconnect  these  systems  with  each 
other  to  form  computer  networks.  DECNET  Phase  II  products  allow 
point-to-point  physical  and  logical  connections.  DECNET  Phase  III 
products  extend  the  logical  connectivity  through  routing  (Ref.  16:17). 
Phase  II  and  III  products  can  be  intermixed  in  the  network. 

In  order  to  satisfy  widely  varying  applications*  DECNET  allows  the 
user  to  build  networks  from  a  wide  range  of  systems  and  communications 
components.  DECNET  allows  the  user  to  interconnect  systems  using  serial 
synchronous  facilities.  When  configuring  DECNET  systems*  both  ends  of 
any  giv^n  link  must  use  the  same  type  of  communications  discipline 
running  at  the  same  line  speed  (Ref.  15:331-339). 

DECNET  is  implemented  from  a  set  of  layered  network  protocols  (ISO 
OSI  Model)*  each  of  which  is  designed  to  fulfill  specific  functions 
within  the  network.  Collectively*  these  protocols  are  known  as  the 
Digital  Network  Architecture  (DNA)(Ref.  16:Vol  1). 


DMA  nodules  in  a  layer  typically  use  the  services  of  nodules  in  the 
layer  imnediately  below.  Some  layers  may  contain  more  than  one  type  of 
module  (as  is  the  case  in  Phase  II  DECNET  Protocols).  Each  module 
specified  by  DNA  operates  as  a  "black  box'*.  That  is*  the  operation 
within  the  black  box  is  transparent  to  other  layers  and  to  equivalent 
modules  in  other  nodes.  The  architecture  does  not  define  specific  code 
for  implementing  modules.  It  only  defines  specific  operations  that  the 
modules  must  perform.  The  architecture  specifies  two  kinds  of 
relationships  between  modules: 


1.  Interfaces.  Interfaces  are  the  relationships  between 
different  modules  that  are  usually  in  the  same  node. 

2.  Protocols.  Protocols  are  the  relationships  between 
equivalent  modules  that  are  usually  in  different  nodes. 


The  architecture  specifies  common  error  reporting,  operational 
parameters*  and  counters  that  certain  layers  must  maintain.  This 
standardization  ensures  that  maintenance*  error  logging,  and  network 
management  can  take  place  consistently.  Finally*  DNA  is  an  open-ended 
architecture.  Future  phases  of  DNA  may  model  additional  layers, 
additional  modules  within  existing  layers,  or  alternative  models  for 
certain  layers.  A  brief  description  of  DECNET  Phase  II  and  Phase  III 
architectures  follows. 


DECNET  Phase  II.  Figure  17,  Page  90,  shows  the  building  of 
information  for  each  layer  of  the  DECNET  Phase  II  DNA.  Each  protocol 
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Figure  17  Ewnet  ProtocoL  Building 


layer  present  is  defined  as  follows  (Ref.  16): 

1.  User  Layer.  This  layer  contains  all  user-supplied 
functions.  It  is  the  highest  layer  in  the  Phase  II  DNA  structure 
(Ref.  16:Vol  I). 

2.  Network  Application  Layer.  This  layer  provides  the  network 
functions  for  the  user  layer.  Modules  in  this  layer  include  network 
remote  file  access  modules*  a  remote  file  transfer  utility*  and  a 
remote  system  loader  module.  The  protocol  used  for  remote  file 
access  and  file  transfer  is  the  Data  Access  Protocol  (DAP)(Ref. 
16 :Vol  II). 

3.  Network  Services  Layer.  This  layer  provides  a 
location- independent  communication  mechanism  for  both  the  user  layer 
and  the  network  application  layer.  Two  network  application  modules 
may  communicate  with  each  other  by  means  of  the  network  services 
layer  regardless  of  their  netrork  locations.  The  protocol  used 
between  network  service  modules  is  the  Network  Services  Protocol 
(NSP) (Ref .  16 :Vol  III). 

4.  Transport  Layer.  This  layer  provides  a  mechanism  for  the 
network  services  layer  to  send  a  unit  of  data  (a  packet)  from  any 
node  in  a  network  to  any  other  node  in  the  network.  This  layer* 
while  conceptually  seperate  from  the  network  service  layer*  is 
sufficiently  simple  in  Phase  II  DNA  that  its  specification  is 
encompassed  by  the  NSP  specification  described  above  (Ref.  16:Vol 


5.  Data  Link  Layer.  This  layer  provides  the  transport  layer 
with  an  error-free  communication  mechanism  between  adjacent  nodes. 
The  data  link  module  specified  for  this  layer  implements  the  Digital 
Data  Communications  Message  Protocol  (DDCMP) .  The  functions 
provided  by  this  layer  are  independent  of  communication  facility 
characteristics  (Ref.  16:Vol  IV). 

6.  Physical  Link  Layer.  Modules  in  the  physical  link  layer 
manage  the  physical  transmission  of  data  over  a  channel.  The 
functions  of  modules  in  this  layer  include  monitoring  channel 
signals,  clocking  on  the  channel,  handling  interrupts  from  the 
hardware,  and  informing  the  data  link  layer  when  a  transmission  is 
complete.  Implementations  of  this  layer  encompass  parts  of  device 
drivers  for  each  communications  device  as  well  as  the  communications 
hardware  itself.  The  hardware  includes  devices,  modems,  and  lines. 
In  this  layer,  industry  standard  electrical  signal  specifications 
such  EIA  RS-232-C  or  CCITT  V.24  operate  rather  than  protocols  (Ref. 
16 :Vol  V). 

The  services  between  modules  in  the  physical  link  and  data  link 
layers  are  less  sophisticated  than  those  provided  by  the  transport  layer 
modules.  The  modules  that  reside  in  the  physical  link  and  data  link 
layer  provide  services  for  moving  data  from  a  given  node  to  an  adjacent 
node  only.  The  modules  in  the  transport  and  higher  layers  provide 
services  for  moving  data  from  a  given  node  to  any  other  node  in  the 
network. 
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DECNET  Phase  III.  Figure  17,  page  90,  shows  the  building  of 
information  as  data  passes  through  the  Phase  III  DNA  layers.  Each  of 


the  Phase  III  DNA  layers  are  defined  below: 

1.  User  Layer.  The  user  layer  contains  most  user-supplied 
functions.  It  also  contains  the  Network  Control  Program,  a  network 
management  module  that  gives  system  managers  access  to  lower  layers 
to  control  and  observe  the  network  from  a  terminal  (Ref.  17:Vol  I). 

2.  Network  Management  Layer.  Modules  in  the  network 
management  layer  provide  user  control  of  and  access  to  operational 
parameters  and  counters  in  lower  layers.  Network  management  also 
performs  down-link  loading,  up-line  dumping,  and  test  functions.  In 
addition,  the  network  management  performs  event  logging  functions. 
This  layer  is  the  only  one  that  has  direct  access  to  each  lower 
layer.  The  protocols  for  this  layer  are  (Ref.  17 :Vol  II): 

A.  Network  Information  and  Control  Exchange  (NICE) 
Protocol.  This  is  used  for  triggering,  down-line  loading, 
up- line  dumping,  testing,  reading  parameters  and  counters, 
setting  parameters,  and  zeroing  counters. 

B.  Event  Logger  Protocol.  This  is  used  for  recording 
significant  occurances  in  lower  layers.  An  "event"  could  result 
from  a  line  coming  up,  a  counter  reaching  a  threshold,  a  node 
becoming  unreachable,  and  so  on. 
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3.  Network  Application  Layer.  The  network  application  layer 
provides  generic  services  to  the  user  layer.  Services  include 
remote  file  access,  remote  file  transfer,  and  resource  managing 
programs.  This  layer  contains  both  user-  and  Digital-supplied 
modules.  The  following  modules  execute  simultaneously  and 
independently  in  this  layer  (Ref.  17 sVol  III): 

A.  Data  Access  Protocol  (DAP).  This  is  used  for  remote 
file  access  and  transfer. 

B.  Loopback  Mirror  Protocol.  This  is  used  for  network 
management  logical  link  loopback  tests. 


4.  Session  Control  Layer.  The  session  control  layer  defines 
the  system-dependent  aspects  of  logical  link  communication.  Session 
control  functions  include  name  to  address  translation,  process 
addressing,  and  process  activation  and  access  control.  The  module 
at  this  level  is  called  the  Session  Control  Protocol  (Ref.  17:Vol 
IV). 

5.  Network  Services  Layer.  The  network  services  layer  is 
responsible  for  the  system- independent  aspects  of  creating  and 
managing  logical  links  for  network  users.  The  Network  Services 
Protocol  (NSP)  module  performs  data  flow  control,  end-to-end  error 
control,  and  the  segmentation  and  reassembly  of  us  r  messages  (Ref. 
17 :Vol  V). 
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6.  Transport  Layer.  Modules  in  the  transport  layer  route  user 
datat  contained  in  packets ,  to  its  destination.  The  Transport 
Protocol  module  also  provides  congestion  control  and  packet  lifetime 
control  (Ref.  17:Vol  VI). 

7.  Data  Link  Layer.  This  is  DDCMF  as  described  previously  for 
Phase  II  DNA  (Ref.  17:Vol  VII). 

8.  Physical  Link  Layer.  This  module  is  the  same  as  described 
previously  for  Phase  II  DNA  (Ref.  17:Vol  VIII). 

The  three  higher  layers  each  interface  directly  with  Session 
Control  for  logical  link  services.  Each  layer  interfaces  with  the  layer 
directly  below  to  use  its  services.  The  User  Layer  interfaces  directly 
with  the  Network  Application  Layer  as  well.  In  addition.  Network 
Management  modules  interface  with  each  lower  layer  directly  for  access 
and  control  purposes.  Finally,  Network  Management  interfaces  directly 
with  the  Data  Link  Layer  for  service  functions  that  do  not  require 
logical  links. 

EWNET  Design.  The  primary  purpose  of  a  network  is  to  pass  data 
from  a  source  in  one  node  to  a  destination  is  another.  Because  EWNET  is 
designed  around  the  Phase  II  and  III  DNA  structure,  it  is  important  to 
understand  how  data  flows  through  the  DNA  layers  and  between  EWNET 
nodes.  Data  traveling  from  one  node  in  a  network  to  another  passes  from 
a  source  process  in  the  user  layer  down  through  each  layer  of  the 
appropriate-phase  DNA  hierarchy  of  the  source  node  or  host  before  being 
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transmitted  across  a  line.  If  the  destination  node  or  host  is  not 
adjacent,  the  data  must  then  travel  up  to  the  Transport  Layer  of  the 
adjacent  node,  where  it  is  routed  (or  switched),  sent  back  down  through 
the  two  lower  layers,  and  transmitted  across  the  next  line  in  the  path. 
The  data  keeps  traveling  in  this  manner  until  it  reaches  its  destination 
node  or  host.  At  this  node  or  host,  the  data  passes  up  the  hierarchy  of 
layers  to  the  destination  process. 

All  hosts  attached  to  EWNET  will  contain  Phase  II  DNA  software, 
while  all  EWNET  nodes  will  contain  Phase  III  DNA  software.  This 
configuration  is  appropriate  for  EWNET  since  the  use  of  Phase  II  DNA 
software  in  the  hosts  will  reduce  the  amount  of  network  software  that 
must  be  present  (homogeneous  network)  in  the  host.  This  satisfies  the 
requirements  that  the  hosts  (ISS  computers)  contain  the  least  amount  of 
network  software  possible;  and  that  host  should  not  be  allowed  to 
perform  routing  functions.  Since  the  EWNET  nodes  are  the  center  of  the 
star  topology,  they  will  be  required  to  perform  network  packet  routing 
and  thus  will  require  the  Phase  III  DNA  software.  Figures  18,  19.  and 
20  on  pages  97,  98,  and  99,  are  the  data  flow  graphs  for  EWNET. 

Snmmaia 

This  chapter  has  translated  the  hardware  and  software  requirements 
into  a  commercially  available  system  design.  The  hardware  design 
specifies  the  topology  to  be  used,  the  hosts  to  be  included,  the 
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f,ure  18  Host.-to-llosl/Node-to-Host  Data  Flow 


Figure  19  Node-to-Node  Data  Flow 


Node  f 1  Node  #2 


Figure  20  Host-to-Host  Data  Flow 


specific  node  to  use*  and  the  transmission  medium  to  be  used  for  each 
EWNET  link.  Each  of  these  design  decisions  is  based  upon  the 
requirements  analysis  and  supported  by  background  data  gained  from 
researching  the  various  design  options.  The  software  design  is  based 
upon  the  structured  specification  in  Appendix  C  and  was  derived 
primarily  by  studing  the  commercially  available  network  products  such  as 
IBM’s  SNA.  Xerox’s  ETHERNET,  and  Digital's  DECNET.  Once  the  network 
product  best  suited  to  EWNET  functional  requirements  was  chosen*  further 
refinement  of  the  commerically  available  network  product  was  required  to 
fine  tune  the  network  configuration  to  the  EWNET  requirements.  The 
Digital  Equipment  Corporation’s  DECNET  was  chosen  and  refined  because  it 
best  suited  EWNET's  functional  requirements  and  because  the  DECNET  was 
designed  around  the  X.25  communications  protocol  (Ref.  15:348). 
Additionally.  DECNET  is  completely  supported  by  the  Digital  Equipment 
Corporation's  Internets  product  (Ref.  15:340-349).  The  Internet 
products  are  data  transfer  facilitators  (not  hardware  emulators)  that 
provide  mechanisms  for  interchanging  data  with  IBM’s  SNA  protocol 
structure  and  remote  batch  workstation,  UNIVAC's  remote  UN1004/NTR 
batch,  and  CDC’s  interactive  MUX200  batch.  Finally,  Digital  Equipment 
Corporation  is  in  the  process  of  implementing  Packetnets  (public  packet 
switching  networks)  based  on  the  X.25  protocol  throughout  Canada,  the 
United  States,  and  France;  and  initial  local  computer  DECNET  networks 
are  being  designed  by  Digital  Equipment  Corporation  that  will  be  based 
entirely  upon  the  ETHERNET  concept. 

Due  to  the  above  discussion  it  is  apparent  that  Digital  Equipment 
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Corporation's  DECNET  is  not  just  another  network  design;  is  is  a 
complete  networking  concept  which  allows  future  growth  as  technological 
advances  are  made. 

The  complete  structured  design  of  EWNET  is  contained  in  the  Network 
Profile  located  in  Appendix  D  (Refs.  1 8; 19) •  Appendix  D  was  included 
as  a  tool  to  be  used  by  the  EWNET  Management  group  in  the  procurement  of 
the  EWNET.  Appendix  D  was  written  in  the  exact  format  required  by  the 
Digital  Equipment  Corporation,  but  does  not  contain  all  data  necessary 
to  procure  the  network  at  this  time  since  this  thesis  study  was 
concluded  before  complete  information  on  all  hosts  became  available  (had 
not  been  procurred). 

This  chapter  allocated  all  off-line  host  software  modules  to 
particular  node  processors  in  the  network. 


Conclusions 


This  investigation*  the  development  of  EWNET,  was  based  upon  the 
actual  requirements  of  the  Electronic  Warfare  Engineering  Branch 
Laboratory.  The  user  interviews  were  used  both  to  determine  what  the 
exact  user  requirements  were  and  to  provide  a  vehicle  to  document  these 
requirements.  From  these  user  identified  requirements  the  functional 
requirement  specifications  of  EWNET  were  determined. 

The  EWNET  functional  requirement  specifications  were  broken  down 
into  the  hardware  specification  and  the  software  structured 
specification.  This  portion  of  the  investigation  was  the  most 
time-consuming.  The  process  of  determining  these  specifications 
required  that  iterative  design  decisions  be  made  as  the  specifications 
evolved. 

The  time  spent  developing  the  functional  requirement  specifications 
proved  to  be  worthwhile  once  the  design  phase  was  started.  Because  of 
the  amount  of  partitioning  that  had  to  be  done  to  arrive  at  the 
specification  level*  the  design  proved  to  be  straightforward.  The 
evaluation  and  selection  of  a  commercially  available  network  product  and 
the  tuning  of  this  network  configuration  lead  to  a  network  design  that 
was  unique  with  respect  to  the  EWNET  functional  requirements. 

The  network  was  designed  in  such  a  way  to  minimize  the  amount  of 
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protocol  software  residing  in  each  ISS  so  that  minimum  effect  would  be 
felt  by  each  ISS  at  implementation  time.  The  Engineering  Branch  Host 
Computer  functions  and  the  EWNET  functions  were  combined  to  eliminate 
the  need  for  virtual  terminal  protocols.  The  most  difficult  portion  of 
the  investigation  concerned  the  vast  amount  of  information  existing  on 
network  designs*  forcing  extensive  reading  on  the  part  of  the  author. 

The  implementation  and  testing  of  the  EWNET  configuration  is  in 
process  at  the  Electronic  Warfare  Division,  Robins  AFB*  Georgia.  The 
implementation  is  proceeding  in  steps j  each  star  configuration  is  being 
set  up  and  tested  before  the  core  loop  configuration  will  be  added. 
This  approach  is  giving  the  ISS  lead  engineers  time  to  familiarize 
themselves  with  the  benefits  of  using  the  network. 

Recent  news  from  Robins  AFB  indicates  that  the  EWNET  is  already 
proving  to  be  a  valuable  tool  to  the  Electronic  Warfare  Division;  the 
time  spent  in  obtaining  databases  from  other  similar  ISSes  has  been 
significantly  reduced,  thereby  freeing  up  valuable  time  for  engineers  to 
perform  other  task. 

In  summary,  through  the  user  interviews.  Structured  Analysis 
techniques,  and  Structured  Design  techniques,  a  top-down  design  of  EWNET 
was  achieved.  All  primary  requirements  of  the  Electronic  Warfare 
Engineering  Branch  Laboratory  for  file  transfer  capability,  resource 
sharing  and  ISS  independence  have  been  met  in  the  design.  The 
structured  approach  allowed  the  interfaces  between  the  layers  of 
protocol  to  be  clearly  defined  and  together  with  the  functional 
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requirement  specifications  allowed  the  selection  of  an  appropriate 
commercially  available  network  product  to  be  signigicantly  simplified* 
leaving  only  network  enhancements  to  be  considered  in  follow-on 
investigations. 

Recommnflatipaa 

B ecauae  the  selection  of  a  design  for  EWNET  was  limited  to  a 
commercially  available  network  design  which  is  already  in  the 
implementation  and  testing  phases*  follow-on  investigations  will  be 
limited  to  enhancements  to  the  EWNET.  The  exact  enhancements  and 
specific  task  involved  which  the  Engineering  Branch  Laboratory  would  be 
interested  in  are  listed  below: 

1.  Data  link  to  Eglm  AFB,  FL.  Math  Laboratory. 

a.  Determine  best  approach  (satellite  or  landline). 

b.  Develop  and  implement  the  necessary  virtual  terminal 
protocol. 

2.  Standardize  all  outputs  from  the  network  into  one  format. 

3.  Automate  all  ISS  and  EWNET  documentation. 

4.  Implement  a  network  command  terminal  capability  so  that 
standalone  terminals  can  be  added  to  the  network. 
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5.  Evaluate  DECnet  statistical  network  data  and  make 
recommendations  for  additional  capability  (i.e.,  software  monitors* 
hardware  monitors*  or  standalone  statistics  collecting  node). 

6.  Evaluate  the  EWNET  routing  algorithm  when  the  network  grows 
to  include  an  additional  node. 

a.  Design  new  algorithm 

b.  Test  algorthim  using  a  simulation  of  the  EWNET 

c.  Implement  new  algorithm 

A  simulation  for  an  AFLC  Bulk  Data  Network  has  been  formulated  in 
another  research  project  at  the  Air  Force  Institute  of  Technology  (Ref. 
20).  This  simulation  was  written  by  a  fellow  Robins,  AFB  employee  using 
Pascal  to  represent  a  specified  network  design.  But,  in  conversations 
with  the  simulation  author*  it  was  determined  that  slight  modifications 
(packet  length*  etc.)  could  result  in  the  tailoring  of  the  simulation  to 
represent  the  EWNET  cofiguration.  This  simulation  could  then  be  hosted 
on  any  of  the  computers  within  the  Engineering  Branch  Laboratory  and  act 
as  a  valuable  testing  tool  in  the  evaluation  of  future  enhancements  to 
the  EWNET.  Finally*  it  is  suggested  that  extensive  study  and  evaluation 
of  the  DECnet-ETHERNET  concept  be  undertaken  once  tne  Digital  Equipment 
Corporation  makes  the  documentation  available.  The  study  should  focus 
on  the  advantages  to  the  Engineering  Branch  Laboratory  of  implementing 
this  protocol  structure  on  EWNET. 


Bibliography 


1.  Hobart,  William  C.  Design  of  a  Local  Computer  Network  for  the 
Air  Force  Institute  of  Technology  Digital  Engineering  Laboratory.  MS 
Thesis.  Wright-Patterson  AFB,  Ohio:  School  of  Engineering,  Air  Force 
Institute  of  Technology,  March  1981. 


2.  Vogler,  F.  H.  and  J.  A.  Copland. 
Standardized  Integration  Support  Station  System  Study.  Georgia 
Institute  of  Technology  Study.  Engineering  Experiment  Station,  Altanta, 
Georgia,  May  1980. 


3.  Georgia  Institute  of  Technology,  Engineering  Experiment  Station, 
Systems  Engineering  Laboratory.  Standardized  Integration  Support 
Station  System  Specification.  Altanta,  Georgia,  1980. 


4.  McQuillan,  John  M.  "Local  Network  Architecture",  Computer  Design. 
4:18  -  26  (May  1981). 


5.  Dineaon,  Mark  A.  "Broadband  Local  Networks  Enhance  Communication 
Design",  Electronic  Design  News.  12:  77  -  85  (March  1981). 


6.  Martin,  James.  Design  of  Man-Computer  Dialogues.  Englewood  Cliffs, 
N.  J.  :  Prentice-Hall,  Inc.,  1973. 


7 .  Air  Force  Logistic  Command  Headquartera_Staf f  Letter. 

Wright-Patterson  AFB,  Ohio.  1  April  1981. 


8.  Levy,  Walter  A.  "Too  Many  Networks,  Not  Enough  Gateways", 

Mini-Micro  Systems.  9  :  104  -  109,  (September  1980). 


9.  Weinbery,  Victor.  Structured  Analysis.  New  York,  N.  Y. 
Your don,  Inc.,  1979. 


10.  TRW  Defense  and  Space  Systems  Group.  Long  Ranye  Logistics 

Support  Plan  for  Embedded  Computer  Systems - Phase  III  Pratt.  Redondo 

Beach,  California,  April  1981. 


11.  Tanenbaum,  Andrews.  Computer  Networks.  Englewood  Cliffs,  New 


106 


Yersey:  Prentice-Hall,  Inc.,  1981. 


12.  Davies,  D.  W.,  D.  L.  A.  Barber,  W.  L.  Price,  and  C.  M. 
Solomonides .  Computer  Networks  and  Their  Protocols.  New  York,  N.  Y.: 
John  Wiley  and  Sons  Ltd.,  1979. 


13.  Digital  Equipment  Corporation.  VAX  11  Software  Handbook. 
Description  of  VAX-11/780  Software.  Digital's  Sales  Support  Literature 
Group,  1980. 

14.  Digital  Equipment  Corporation.  PDP  11  Processor  Handbook. 
Description  of  PDP-11/04/24/34A/44/70  Processors.  Digital’s  Sales 
Support  Literature  Group,  1981. 

15.  Digital  Equipment  Corporation.  PDP  11  Software  Handbook. 
Description  of  PDP-11  Software  Products.  Digital's  Sales  Support 
Literature  Group,  1980-81. 

16.  Digital  Equipment  Corporation.  Digital  Network  Architecture. II 
Protocol  Specifications: _ Volumes  I.  II.  III.  IV,  and  V.  Description 

of  the  Digital  Network  Architecture  -  Phase  II  Implementation  of  All 
Protocol  Layers.  Digital's  Sales  Support  Literature  Group,  1980. 


17 .  Digital  Equipment  Corporation.  Digital  Network  Architecture  III 

Protocol  Specifications: _ Volumes  I.  ILi  IU«  I-Y.»  .V*.  VI »  VII*  and 

VIII.  Description  of  the  Digital  Network  Architecture  -  Phase  III 

Implementation  of  all  Protocol  Layers.  Digital's  Sales  Support 
Literature  Group,  1981. 

18.  Digital  Equipment  Corporation.  Peirpheral  Handbook.  Descriptions 
of  all  Peripheral  Equipment  Manufactured  by  the  Digital  Equipment 
Corporation.  Digital's  Sales  Support  Literature  Group,  1981. 


19.  Digital  Equipment  Corporation. 
Terminals  and  Communications  Handbook.  Descriptions  of  all  the 
Terminals  and  Interface  Products  Manufactured  by  the  Digital  Equipment 
Corporation.  Digital's  Sales  Support  Literature  Group,  1980. 


20.  Stewart,  Stephen.  Simulation  of  the  AFLC  Bulk  Data  Network.  MS 
Thesis,  Wright-Patterson  AFB,  Ohio:  School  of  Engineering,  Air  Force 
Institute  of  Technology,  December  1981. 


107 


Append.  A 

User  Interview  Results 


This  appendix  contains  a  compilation  of  the  results  of  the  user 
interviews  that  were  conducted  in  the  requirements  analysis  phase  of  the 
investigation  at  Robins  AFB,  Georgia  on  10.  11.  and  12  June  1981.  These 
results  provided  the  basis  for  the  specification  of  the  EWNET  functional 
requirements  in  Chapter  II. 
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To:  MMRR  (Mr.  Joe  Black) 

Subject:  AFIT  Thesis  :  Electronic  Warfare  Local  Computer  Network 

(EWNET) 

From  :  AFIT/ENE  (Mr.  Robert  H. Stokes,  Box  4083) 


1.  Attached  you  will  find  25  copies  of  the  interview  I  am  using  to 
obtain  data  necessary  to  design  the  Electronic  Warfare  Engineering 
Branch  Local  Computer  Network  (EWNET). 


2.  These  copies  are  provided  for  distribution  to  yourself  and  the  MMRR 
sections  listed  below: 

1.  MMRRA 

2.  MMRRC 

3.  MMRRI 

4.  MMRRV 

5.  MMRRW  (Info  Copy  Only) 

6.  MMRRF  (Info  Copy  Only) 

I  wish  each  section  chief  to  retain  a  copy  and  send  the  extras  to  the 
following  system  lead  engineers: 

1 .  AN/ALR-46 

2.  AN/ALR-62 

3 .  AN/ALR-6  9 

4.  AN/ALQ-119 

5.  AN/ALQ-125 

6.  AN/ALQ-131 

7.  AN/ALQ-155 

8.  AN/APR-38 

9.  B-52 

10.  F-15  TEWS 
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11.  EF-111A 


12.  FLTS 

13.  EWOLS/ECSAS 

14.  DNIVAC-1108 

15.  Engineering  Branch  Standardization  Group 

Plus  any  systems  the  section  chiefs  feel  should  be  included  in  this 
list.  Feel  free  to  make  additional  copies  of  the  interview  if  the  need 
arises . 


3.  Each  system  engineer  should  review  the  EWNET  interview,  answering 
those  questions  that  are  self  explanatory,  within  the  next  two  weeks.  I 
will  be  arriving  at  WR-ALC  on  the  morning  of  10  June  1981,  and  will  be 
available  to  interview  each  system  engineer  and  to  answer  questions 
about  the  interview  portions  that  are  not  self  explanatory.  I  will  only 
be  able  to  spend  3  days  at  WR-ALC  before  returning  to  Ohio.  Therefore, 
I  hope  that  the  two  weeks  before  I  arrive  will  be  ample  time  for  all 
users  to  review  the  interview  and  be  prepared  for  my  arrival.  In  the 
interest  of  expediency,  I  would  appreciate  it  if  each  section  chief 
would  query  the  system  engineers  in  his  command  and  meet  with  tne  other 
section  chiefs  to  setup  an  interview  schedule  for  me.  I  think  it  will 
take  approximately  50  minutes  per  interview  if  each  system  lead  engineer 
is  interviewed  separately.  If  the  section  chief  wishes,  I  can  be 
prepared  to  interview  all  system  lead  engineers  in  his  section  at  one 
time  in  a  group  discussion.  The  interview  schedule  should  be  delivered 
to  Mr.  Black's  office  COB  Tuesday  9  June  1981,  for  immediate  pickup  by 
Mr.  Stokes  on  the  morning  of  10  June  1981. 

4.  I  am  fully  aware  of  the  limited  time  and  resources  at  your  disposal 
and  hope  that  what  I  have  requested  will  not  cause  undue  hardships  on 
anyone.  I  only  wish  to  design  a  network  that  will  meet  everyone's  needs 
within  the  Engineering  Branch,  while  providing  the  maximum  feasable 
support  for  the  ISSes.  I  can  only  obtain  this  goal  if  I  have  your  help, 
without  it  I  must  rely  on  my  own  limited  knowledge  of  all  the  system 
requirements.  Your  efforts  in  this  area  are  much  appreciated. 


Robert  H.  Stokes 
MSEE  Computer  Systems 


i 

i 

I 


no 


EWNET  INTERVIEW 


Introductory  Narrative 

I  am  in  the  Preliminary  design  phase  of  the  Electronic  Warfare 
Branch  Local  Computer  Network  (EWNET)  and  am  attempting  to  determine  the 
uses  envisioned  for  EWNET  as  well  as  all  functional  requirements 
associated  with  it.  Therefore,  I  would  appreciate  any  help  that  you  can 
give  me  in  determining  these  requirements.  Hopefully,  the  questions 
that  I  have  prepared  in  the  interview  outline  will  provide  a  framework 
within  which  you  can  communicate  your  ideas  to  me  in  this  area. 

The  interview  is  divided  into  four  sections.  The  first  section 
lists  typical  uses  of  local  computer  networks,  asks  you  to  evaluate  the 
benefits  of  having  the  capability  for  each  use  on  EWNET,  and  then  asks 
you  to  specify  which  uses  you  would  like  to  see  implemented  first.  The 
second  section  lists  some  of  the  functional  requirements  that  must  be 
determined  and  asks  specific  questions  dealing  with  each  of  these 
requirements.  At  the  end  of  this  section,  you  will  be  asked  to  rate 
each  of  the  functional  requirements  on  a  scale  from  “DOES -NOT-AP PLY**  to 
“MUST  HAVE*".  The  third  section  requests  that  you  express  any  ideas  that 
you  have  concerning  EWNET  that  were  not  expressed  by  your  responses  to 
the  questions  in  the  first  two  sections.  Finally,  the  fourth  section 
contains  questions  related  to  design-oriented  requirements  and  deals 
with  network  management.  Users  are  not  required  to  answer  these 
questions,  only  section  and  branch  management  need  respond,  although  all 
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inputs  will  be  appreciated. 
Name  of  the  Person  Interviewed. 

Date  of  Interview _ 

EW  System  Represented _ 


Section  I  :  Projected  Uses  of  EWNET 
A.  Resource  Sharing 

!•  Peripheral  Sharing  =  capability  to  access  network  from  any 
terminal  and  access  any  peripheral  in  the  network  from  any  host. 

2.  File  Access  and  Transfer  =  capability  to  transfer  files 
between  the  devices  and  the  hosts  with  all  file  restructuring 
transparent  to  the  user. 

3.  Software  Tool  Sharing  =  capability  to  access  programs, 
compilers,  cross-assemblers,  and  utility  routines  anywhere  in  the 
network  for  the  user's  program. 

4.  Access  To  ARPANET  =  capability  to  access  ARPANET  from  any 
terminal . 

5.  Access  to  AUTODIN  I  =  capability  to  access  AUTODIN  I  from 
any  terminal. 

6.  Access  To  UNIVAC-1108  =  capability  to  access  the 

UNIVAC-1108  from  any  terminal. 


112 


7.  Threat  Generator  =  capability  to  use  digital  threat 
information  generated  from  a  central  location. 

8.  Flight  Test  Monitor  =  capability  to  monitor  Eglin  AFB 
flight  test  in  real  time.  ** 

B.  Distributed  Processing  =  capability  of  executing  job  processes  that 
can  run  concurrently  on  different  computers. 

C.  Distributed  Databases  =  capability  to  access  and  maintain  databases 
that  are  distributed  across  several  computers  in  the  network  (Central 
Threat  Database). 

D.  Video  =  capability  to  monitor  Eglin  AFB  test  video  (ground  and 
in-flight).  ** 

E.  Fault-Tolerance  =  capability  to  provide  a  more  graceful  degradation 
of  user  service  when  a  network  failure  occurs. 
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F.  Rate  the  Above  Projected  Uses 


i 


t 


1  PROJECTED  USES 

|  VERY  | 

GOOD  I 

MEDIUM 

LITTLE 

1  NO  1 

1 

|  GOOD  | 

I 

USE 

I  USE  I 

1  PERIPHERAL  SHARING 

1  5  I 

4  I 

2 

1 

0  I 

1  FILE  TRANSFERS 

1  8  i 

2  1 

1 

1 

0  1 

1  SOFTWARE  TOOL  SHARING 

|  8  | 

3  1 

1 

0 

0  1 

1  ACCESS  TO  THE  UNIVAC-1108 

1  5  I 

4  I 

1 

1 

2  1 

1  ACCESS  TO  AUTODIN  I 

I  1  1 

1  1 

2 

0 

8  ! 

1  ACCESS  TO  ARPANET 

I  0  [ 

0  I 

0 

4 

8  1 

I  THREAT  GENERATOR 

i  4  | 

5  1 

1 

3 

1  1 

1  FLIGHT  TEST  MONITOR 

i  2  I 

1  I 

3 

3 

3  1 

1  DISTRIBUTED  PROCESSING 

1  2  | 

3  1 

4 

3 

0  1 

1  DISTRIBUTED  DATABASES 

1  2  I 

3  1 

4 

4 

0  1 

|  VIDEO 

1  1  1 

2  1 

3 

2 

4  I 

1  FAULT-TOLERANCE 

1  4  ! 

7  1 

2 

0 

0  1 

(Composite  of  User  Responses) 

G.  What  group  of  things  would  you  like  to  see  implemented  first? 


1.  Peripheral  Sharing _ 4 

2.  Software  Tool  Sharing _ 1 

3.  File  Transfer _ 1 

4.  UNIVAC-1108  Access _ 1 


» 

*  + 
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H.  Prioritize  the  above  group  of  uses  with  related  comments: 

1.  File  Transfers 

2.  Software  Tool  Sharing 

3.  Access  to  the  UNIVAC-1108  -  Backup  of  ISSes*  Common 
Databases*  and  Off-Line  Processing. 

4.  Peripheral  Sharing  -  Critical  peripherals  such  as  plotters 
and  printers. 

5.  Fault  Tolerance  -  No  support  from  DECNET. 

6 .  Threat  Generator 

7.  Rest  of  List  in  any  order. 

**  Interface  to  Eglin  AFB  TM-Stations  and  Math  Lab  has  not  been  defined. 
Possible  satellite  link  to  Eglm  AFB  is  being  considered. 


Section  II  :  Functional  Requirements  of  EWNET 
A.  User-Oriented  Requirements 

1 .  Throughput 

A.  What  computer  /  models  do  you  envision  using  with 
your  ISSes  over  the  next  5  years? 

B.  What  will  be  the  average  utilization  in  hours  per  day? 
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C.  What  will  be  the  maximum  utilization  in  hours  per  day? 


COMPUTER 

NORMAL  USAGE 

MAXIMUM  USAGE 

DNIVAC-1108 

8 

24 

VAX  11/780 

6 

12 

VAX  11/780 

4 

7 

VAX  11/780 

7 

8 

VAX  11/780 

10 

24 

VAX  11/780 

5 

8 

VAX  11/780 

8 

24 

VAX  11/780 

8 

24 

VAX  11/780 

8 

12 

VAX  11/780 

5 

12 

PDP  11/34 

6 

12 

PDP  11/34 

6 

24 

PDP  11/34 

6 

24 

PDP  11/34 

8 

12 

D.  G.  ECLISPE 

5 

12  I  TEMPORARY 

HARRIS  6024/4 

4 

24  1  TEMPORARY 

2.  Response  Time 

Do  you  forsee  any  projected  uses  of  the  network  that 

requires  that  the  response  time  of  the  network  to  a  set  of 

commands  not  exceed  some  threshold? 

NO . . - . 6 

YES — Fast  enough  so  no  data  is  lost  to  a  low  sampling  rate. 
YES — Response  time  due  to  resource  conflict  should  never 
exceed  5  seconds. 

YES—Interactive  terminals  =  5  seconds. 

YES — Interactive  terminals  <  1  second. 

YES — File  transfer  ISS-to-ISS  <  5  minutes. 

3.  User  Interface 
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A.  Vould  symbolic  device  accessing  be  desirable? 

(Making  the  actual  host  that  an  I/O  device  is  connected 

to  transparent  to  the  user.) 

YES . 13 

NO-— . 0 

OPTION - 4 

B.  Should  the  same  be  done  for  software  tools? 

YES . . 13 

NO . . 0 

OPTION - 4 

C.  Do  you  forsee  the  need  for  ISS  /  network  interface 
accounting  data? 


YES . 11 

NO . . -  3 


NOTE: 

Number  oi  times  the  ISS  is  externally  accessed 

D.  What  other  features  should  the  network  present 


to  the  user? 

Built-in-test - 1 

User  prompts  and  ’help*  routines-- -  3 

ISS  independence - 13 


In-house  distribution 


Point-to-point- 


Broadcast- 


4.  Security 


A.  Do  you  forsee  the  running  of  classified  data  or 


programs  on  the  network ,  and  if  so  at  what 


classification? 


SECRET 


B.  Do  you  forsee  the  need  to  protect  databases  on 


the  network  from  unauthorized  access? 


COMMENT: 


2  Element-password  to  protect  need-to-know 
Security  accountability  =  if  the  net  could 
record  time,  destination,  and  password  of 
classified  receiptents,  then  would  be  a  benefit 
to  audits  of  activity  when  problems  arise. 


5.  Availability 


A.  What  is  the  minimum  percentage  of  time  that  you 
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feel  that  the  network  should  be  available? 

B.  What  is  the  reason  for  giving  the  above 
availability? 

100  Z - 6  (0800-1700  hours  +  emergency  changes  5 

day  work  week) 

99.9  Z - 1 

95  Z - 2  (24  hour  day,  downtime  =  5  %) 

90  Z - 1  (network  required  for  full  ISS  capability) 

50  Z - 2 

C.  Special  consideration  for  availability:  Emergency 
changes  should  have  priority  when  field  support  is 
required,  nothing  should  get  in  the  way. 

6.  ISS  Interaction 


How  and  why  do  you  envision  ISS-to-ISS  interaction? 

1.  Internal  to  section  only — - - 5 

2.  No  external  /  limited  external - 10 

3.  Interaction  with  simulation  &  analysis -  1 

4.  Interaction  with  Flight  Line  Tests  Sets -  1 


7.  Other  User-Oriented  Requirements? 

1.  Common  network  command  language - 2 

2.  Central  documentation - 2 

3.  Word-processor - 5 
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4.  Data  link  to  Elint  sources 


5. 


6. 


7. 


Overflow  /  surge  load  handling - 

(Using  another  ISS's  terminals 
to  operate  your  own  ISS) 
Self-configuring  through  periodic 
status  checks  of  the  network  members-' 
Seal-time  capabitity  where  one 
ISS  takes  complete  control  of  network 
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What  other  comments  or  suggestions  do  you  have  concerning  the 
projected  uses  and/or  functional  requirements  of  EWNET? 

1.  The  network  software  must  be  interrupt-driven.  (Undecided) 

2.  It  would  be  nice  to  be  able  to  interrogate  the  network  to 
find  a  file  that  was  sent.  (6) 

3.  The  network  should  not  be  used  for  general  software 
development.  (4) 

4.  It  should  be  easy  to  initialize  the  network  with  an 
arbitrary  subset  of  the  nodes  available  on  the  network.  (4) 
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5.  The  number  of  nodes  and  their  locations  should  be 

addressed.  (4) 

6.  The  number  of  ISSes  per  node  should  be  addressed.  (4) 

7.  Fiber  optics  should  be  used  for  the  interface  cables.  (4) 

8.  The  network  must  be  designed  for  a  high  level  of 
interaction  for  future  growth  but  must  be  capable  of  implementation 
with  very  limited  capabilities.  (13) 


Section  IV  :  Design-Oriented  Functional  Requirements 


The  following  requirements  are  not  user-oriented  and  should  be 
answered  by  section  and  branch  management.  Section  and  branch 
management  are  being  asked  to  answer  the  questions  in  this  section  since 
no  single  network  management  group  presently  exists  within  the 
Engineering  Branch. 

Management  Title _ 

A.  Design-Oriented  Requirements 

1.  Flexibility 

A.  What  changes  do  you  see  being  made  to  the  network 
during  the  next  few  years? 

1.  More  hosts  and  devices  being  added - 6 
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2.  Being  used  more  for  non-EW  purposes - 3 

3.  Workload  changing  from  mainly  file  transfers - 3 

4.  More  software  development  systems  added - 5 

5.  Expanded  use  of  on-line  threat  database - 1 

6.  Usage  expansion  as  value  is  identified - 1 


B.  How  important  do  you  feel  it  is  for  EWNET  to  be 
easily  reconf igurable  with  respect  to  the  following? 

I  NETWORK  SUBCOMPONENTS  I  VERY  J  SOME  1  NOT  I 

I  NEW  COMPUTERS  AND  DEVICES  |  7  |  3  I  0  [ 

I  NEW  TOPOLOGIES  I  2  |  3151 

I  NEW  PROTOCOLS  I  2  |  2  |  6  I 

I  NEW  TRANSMISSION  MEDIUM  I  2  i  3151 

I  SERIAL -TO-PARALLEL  I  1  j  7  I  2  I 

(Composite  of  User  Responses) 

) 

2.  Per  ormance  Monitoring 

What  performance  monitoring  capabilities  should 

EWNET  have? 

1.  Collect  accounting  data 

2.  Collect  node  statistics' 

3.  Hardware  monitors - 

4.  Software  monitors - 


9 

7 

1 

7 
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5.  Monitor  network  bottlenecks - 9 

6.  Monitor  network  status - S 

7  .  Performance  monitoring  node - 3 

NOTE: 


To  protect  from  network  slowdown  must  be  on  demand 
basis  only. 

3.  Distributed  Processing  Language 

What  language(s)  would  you  like  to  see  implemented  on 
all  or  most  of  the  hosts  if  a  distributed  processing 
capability  is  implemented? 


1.  Jovial  J-73 . 4 

2.  Pascal - 3 

3.  ADA . 10 

4.  Fortran - 6 

5.  Basic -  5 

NOTE: 


ADA  has  powerful  control  structures  for  distributed 
processing. 

4.  Other  Design-Oriented  Requirements 

Are  there  any  other  design  oriented  requirements  that 

should  be  addressed? 


1.  System  should  contain  dual  pass-word  access 


2.  Infinite  queue  detection 


B.  How  would  you  rank  the  functional  requirements  for  the  above  areas? 


I  AREA  I  NOT  I  MARGIN  !  APPLY  I  VERY  I  MUST  | 

I  I  APPLY  |  APPLY  I  I  APPLY  |  HAVE  | 


I  FLEXIBILITY  I  0  I  0  I  2  I  3  I  4  I 


I  PERFORMANCE  MONITORING  I  0  I  0  I  4  I  3  I  2  I 


I  DIST.  PROCESS  LANGUAGE  I  0  I  0  I  6  I  1  I  2  | 


(Composite  of  User  Responses) 


C.  General  Comments 

A1  Richardson;  "I  see  the  host  processor  group 
handling  the  nodes  and  documentation*  word  processing, 
backup  requirements  for  all  ISSes  connected  to  the 
network.  The  software  common  tools  and  the  database 

must  be  resident  at  nodes  common  to  all  systems.  The 
EWOLS  and  ECSAS  systems  must  be  able  to  operate  through 
the  network  from  any  CRT  terminal  and  not  interfere 
with  ISS  operation”. 

Everyone :  "Don't  want  own  ISS  tied  up  by  someone 


else.  Each  ISS  should  process  its  own  jobs  first 
before  servicing  anyone  else”. 

Management :  "If  it  is  possible,  we  world  like  to  see  the 
functions  performed  by  the  UNIVAC-1108,  performed  by  the 
Network  Node  Computers." 
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Section  V 


List  of  Users  Who  were  Interviewed 


USER'S  NAME 

EW  SYSTEM  CONTROLLED 

OFFICE  SYMBOL 

Mr.  Joe  Black 

Electronic  Warfare  Branch  Chief 

MMRR 

Mr.  John  LaVecchia 

Simulation  &  Analysis  Chief 

MMRRA 

Maj .  A1  Richardson 

Unit  Chief 

MMRRAA 

Mr.  Russell  Decote 

Standardization 

MMRRAA 

Mr.  Jerry  Nachreiner 

ECS  AS 

MMRRAA 

Mr.  Don  Schroeder 

EWOLS 

MMRRAA 

Mr.  Art  Daum 

UNI VAC-11 08 

MMRRAH 

Mr.  Bobby  McDonald 

Jammer  Section  Chief 

MMRRC 

Mr.  Dean  DeLaigle 

ALQ-119  Unit  Chief 

MMRRCB 

Mr.  Dennis  Thomas 

ALQ-155 

MMRRCC 

Mr.  H.  J.  Hildreth 

Integrated  Sys.  Section  Chief 

MMRRI 

Mr.  Jerry  Reynolds 

F-15  TEWS 

MMRRIA 

Mr.  Hal  Maney 

EF-111A  Unit  Chief 

MMRRI  C 

Mr.  Gary  Cox 

USM-464  (FLTS) 

MMRRIC 

Mr.  Bert  Goble 

APR- 3 8 

MMRRI T 

Mr.  Tom  Ridout 

APR-38 

MMRRIT 

Mr.  Tom  Batterman 

RWR  Sys.  Section  Chief 

MMRRV 

Mr.  Phil  Oliver 

ALR-46  Unit  Chief 

MMKRVA 

Mr .  Bob  Smock 

ALR-46 

MMRRVA 

Mr.  John  Louth 

ALR-46 

MMRRVA 

Mr.  N.  Mitin 

ALR-62 

MMRRVB 

Mr.  Harry  Jennings 

ALR-69  Unit  Chief 

MMRRVC 

Appendix  B 

Electronic  Warfare  Engineering  Branch  Laboratory  Floor  Layout  Diagram 

and  Topology  Structure 


This  appendix  contains  a  floor  layout  diagram  of  the  Electronic 
Warfare  Engineering  Branch  Laboratory  at  Robins  AFB,  Georgia.  The 
location  of  all  ISS  computers  with  semi-permanent  locations  are  shown  as 
well  as  the  proposed  locations  of  the  EWNET  node  computers.  Finally, 
the  computer  links  (topology)  that  were  initially  proposed  by  the 
Georgia  Institute  of  Technology  to  connect  the  node  computers  are  shown 
(Ref.  2:10). 
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Structured  Specification 


This  appendix  contains  the  structured  specification  of  the  software 
requirements  for  EWHET.  First,  the  complete  set  of  data  flow  diagrams 
is  included.  These  are  followed  by  the  data  dictionaries  for  the 
high-level  protocol  (user- level) ,  the  architecture- level  protocol,  the 
transport/network-level  protocol,  and  the  link-level  protocol. 
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DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  FLOW  NAME: 
ALIASES : 
COMPOSITION: 

NOTES : 


DATA  FLOW  NAME: 
ALIASES: 

COMPOST ION: 

NOTES: 


ABORT_COMMAND 

NONE 

REFER  TO  DATA  DICTIONARY  FOR  TRANSPORT/NETWORK  LEVEL 
PROTOCOL. 

EXECUTE  TRANSPORT  LEVEL  PROTOCOL  LAYER 


ARCHITECTURE_OPERATION_COMMANDS 

NONE 

ARCHITECTURE_OPERATION_COMMANDS  =  PRIMARY_START_FILE. 
CONFIGURATION 

EXECUTE  EWNET  PROTOCOL  AT  PRIMARY  NODE  LAYER 


CONNECT_REQUEST 

NONE 

REFER  TO  DATA  DICTIONARY  FOR  TRANSPORT/NETWORK  LEVEL 
PROTOCOL. 

EXECUTE  TRANSPORT  LEVEL  PROTOCOL 


DISCONNECT_REQUEST 

NONE 

REFER  TO  DATA  DICTIONARY  FOR  TRANSPORT/NETWORK  LEVEL 
PROTOCOL. 

EXECUTE  TRANSPORT  LEVEL  PROTOCOL  LAYER 


DLE.PACKET 

NONE 

REFER  TO  DATA  DICTIONARY  FOR  LINK  LEVEL  PROTOCOL, 
EXECUTE  LINK  LEVEL  PROTOCOL  LAYER 


ENQ_PACRET 

NONE 

REFER  TO  DATA  DICTIONARY  FOR  LINK  LEVEL  PROTOCOL. 
EXECUTE  LINK  LEVEL  PROTOCOL  LAYER 


i 
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DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


ERROR_REASON 

NONE 

REFER  TO  DATA  DICTIONARY  FOR  TRANSPORT/NETWORK  LEVEL 
PROTOCOL. 

EXECUTE  TRANSPORT  PROTOCOL  LAYER 


FILE_TRANSFER_INFORMATION 

NONE 

A  FLAG  USED  TO  OBTAIN  PROCEDURES  FOR  TRANSFERRING  FILES. 
EXECUTE  HELP  COMMANDS  LAYER 


FILE_TRANSFER_PROCEDURE 

NONE 

FILE_TRANSFER_PROCEDURE  =  TABLE  OF  NECESSARY  ACTIONS  AND 

COMMANDS  DEPENDING  ON  FILE_ 
TRANSFER_TYPE  (SEQUENTIAL,  KEY 
OR  DATA  FILE  ADDRESS) . 

EXECUTE  HELP  COMMANDS  LAYER 


FLOW_CONTROL_ERRORS 

NONE 

REFER  TO  DATA  DICTIONARY  FOR  TRAN SPORT /NETWORK  LEVEL 
PROTOCOL. 

EXECUTE  TRANSPORT  PROTOCOL  LAYER 


GENERAL_INFO RMAT ION 
NONE 

A  FLAG  USED  TO  OBTAIN  GENERAL  NETWORK  INFORMATION. 
EXECUTE  HELP  COMMANDS  LAYER 


HELP_RESPONSE 

NONE 

HELP_RESPONSE  =  7~"fILE_TRANSFER_PR0CEDURE~ 
I  MENU_SELECTION  I 
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NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES : 


I  NETWORK_CONFIGURATION  I 
I  STARTUP.PROCEDURE  I 

EXECUTE  HELP  COMMANDS  LAYER 

EXECUTE  EWNET  PROTOCOL  AT  PRIMARY  NODE  LAYER 


INCOM ING_ARCH I T  ECTUR  E_PACKE  TS 
OUTGOING_ARCHITECTURE_PACKETS 

INCOMING_ARCHITECTURE_PACKETS  =  INCOMING_PRlMARY_NODE. 
ARCHITECTURE_PACKETS 

EXECUTE  EWNET  PROTOCOL  AT  PRIMARY  NODE  LAYER 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 


NOTES : 


INCOMING_LINK_PACKETS 

PRI MARY_IMCOMING_PHYS I CAL.PACKETS 

IMCOMING_PHYSICAL_PACKETS 

OUTGOING_PHYS ICAL_PACKETS 

OUTGOINGS  INK_PACKETS 

SEC  ONDARY.INCOMING.PHY  S I CAL_PACKE  TS 

INCOMING_LINK_PACKETS  =  (11111111)  +  (2{SYNC}8)  + 

I  SOH_PACKET  I 
|  DLE_PACKET  I 
I  ENQ_PACKET  I 


EXECUTE  EWNET  PROTOCOL  AT  PRIMARY  NODE  LAYER 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES : 


INCOMING_NODE_NETWORK .PACKET 
NONE 

REFER  TO  DATA  DICTIONARY  FOR  TRANSPORT/NETWORK  LEVEL 
PROTOCOL. 

EXECUTE  NETWORK  LEVEL  PROTOCOL 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 


INCOMING.PHYS ICAL_PACKETS 

INCOMING_LINK_PACKETS 

OUTGOING.PHYS I CAL.PACKETS 

PR IMARY.IN C  OM ING.PH Y S I C AL_PA CK E  TS 

OUTGOING.LINK.PACKETS 

SECONDARY_INCOMING_PHYSICAL_PACKETS 

SEE  ALIASES 
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NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


9 


EXECUTE  EWNET  PROTOCOL  AT  PRIMARY  NODE  LAYER 


INCOMING_PRIMARY_NODE_ARCHITECTURE_PACKETS 

NONE 

REFER  TO  DATA  DICTIONARY  FOR  ARCHITECTURE  LEVEL  PROTOCOL. 
EXECUTE  ARCHITECTURE  LEVEL  PROTOCOL 


INCOMING_SATELLITE_TRANSPORT_PACKET 

NONE 

REFER  TO  DATA  DICTIONARY  FOR  TRANSPORT/NETWORK  LEVEL 
PROTOCOL. 

EXECUTE  TRANSPORT  LEVEL  PROTOCOL 


INCOMING_TRAN  SPORT_PACKETS 
OUTGOING_TRAN SPORT_PACKETS 

INCOM ING_TRAN  SPO  RT_PACKE  T 3  =  INCOMING_SATELLITE_TRAN SPORT. 
PACKET 

EXECUTE  EWNET  PROTOCOL  AT  PRIMARY  NODE  LAYER 


LIST_OF_ACTIVE_HOST_AND_DEVICE_NAMES 

NONE 

A  FLAG  USED  TO  OBTAIN  THE  CURRENT  NETWORK  CONFIGURATION. 
EXECUTE  HELP  COMMANDS  LAYER 


LOCAL_COMMAND 

NONE 

LOCAL_COMMAND  =  ALL  LOCAL  COMPUTER  COMMANDS. 
EXECUTE  EWNET  PROTOCOL  AT  PRIMARY  NODE  LAYER 


MENU_SELECT ION 
NONE 


MENU_SELECTION  =  I  LIST_OF _ACTIVE_HOST _AND_DEVICE_NAMES  I 
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DESIGN  of  A  LOCAL  COMPUTER  NETWORK  FOR  THE  ROBINS  AFB  ELECTRONI— ETC <UJ 
OEC  61  R  H  STOKES  . 

UNCLASSIFIED  AFIT/GCS/EE/81D-16  NL 


I  F ILE_TRAN  SFER_INFORMATION 
I  PROTOCOL_STARTUP_INFORMATION 

EXECUTE  HELP  COMMANDS  LAYER 


DATA  FLOW  NAME:  NETWORK_CONFIGURATION 

ALIASES :  NONE 

COMPOSITION: 

NETWORK_CONFIGURATION  =  ALL  DATA  IN  THE  DiALOGUE_PROCESS. 

TABLE. 

NOTES:  EXECUTE  HELP  COMMANDS  LAYER 


NOTES : 


NETWORK_HELP_COMMAND 
NONE 

NETWORK_HELP_COMMAND  = 

!  LIST_OF_ACT IVE_HOST_AND_DEVICE_NAMES  I 
!  FILEJTRANSFER^INFORMATION  I 

I  GENE RAL_INFORMAT ION  I 

I  PROTOCOL_START_INFORMATION  I 

NOTES:  EXECUTE  HELP  COMMANDS  LAYER 

EXECUTE  EWNET  PROTOCOL  AT  PRIMARY  NODE  LAYER 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 


OPE  RATOR_COMMANDS 

PRIMARY_OPERATOIL_COMMANDS 

SECONDARY_OPERATORl_COMMANDS 

OPERATOR_COMMANDS  =  T~ ARCH I TECTURE_OPE RAT ION_COMMANDS ~ T 

|  TRAN  SPORT_OPERATION_COMMANDS  | 

I  LOCAL_COMMAND  I 

1  NETWORK_HELP_COMMANDS  I 


NOTES: 


EXECUTE  EWNET  PROTOCOL  AT  PRIMARY  NODE  LAYER 


OPERATOR_DISPLAY 

PRIMARY_OPERATORJ3ISPLAY 

SECONDARY_OPERATORk_DISPLAY 

SEE  ALIASES 

EXECUTE  EWNET  PROTOCOL  AT  PRIMARY  NODE  LAYER 


V 
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DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 


1 
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DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES : 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 
NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES : 


DATA  FLOW  NAME: 
ALIASES : 


OPERATOR_PAS  SWORD_COMMAND 
NONE 

REFER  TO  DATA  DICTIONARY  FOR  TRANSPORT/NETWORK  LEVEL 
PROTOCOL. 

EXECUTE  TRANSPORT  LEVEL  PROTOCOL  LAYER 


OPE  RATOR_START_COMMAND 
NONE 

REFER  TO  DATA  DICTIONARY  FOR  TRANSPORT/NETWORK  LEVEL 
PROTOCOL. 

EXECUTE  TRANSPORT  LEVEL  PROTOCOL  LAYER 


OUTGOING_ARCHITECTURE_PACKETS 

INCOMING_ARCHITECTURE_PACKETS 

SEE  ALIASES 

EXECUTE  EWNET  PROTOCOL  AT  PRIMARY  NODE  LAYER 


OUTGOING_LINK_PACKETS 
INCOMING_LINK_PACKETS 
PRIMARY_INCOMING_PHYS ICAL_PACKETS 
INCOMING_PHYS  ICAL_PACKETS 
OUTGOING_PHYS  ICAL_PACKETS 
SECONDARY_INCOMING_PHYS ICAL_PACKETS 

SEE  ALIASES 

EXECUTE  EWNET  PROTOCOL  AT  PRIMARY  NODE  LAYER 


OUTGOING_NETWORKwPACKETS 

INCOMING_NETWORK_PACKETS 

SEE  ALIASES 

EXECUTE  EWNET  PROTOCOL  AT  PRIMARY  NODE  LAYER 


OUTGOING_PHYS  ICA1_PACKETS 
INCOMING_LINK_PACKETS 
PRIMARY_.INCOMING_.PHYS  ICAL.PACKETS 
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COMPOSITIONS 

NOTES: 

DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 

DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES : 

DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION : 

NOTES: 


INCOMING_PHYS  ICAL_PACKETS 

OUTGOINGJLINKJPACKETS 

SECOND ARY  _INCOMING_PHYSICAL_PACKETS 

SEE  ALIASES 

EXECUTE  EWNET  PROTOCOL  AT  PRIMARY  NODE  LAYER 


OUTGOING_TRAN SPORT_PACKETS 
INCOMING_TRANSPORT_PACKETS 

SEE  ALIASES 

EXECUTE  EWNET  PROTOCOL  AT  PRIMARY  NODE  LAYER 


PRIMARY_INCOMING_PHYS  ICAL_PACKETS 
SECONDARY_INCOMING_PHYS ICAL__PACKETS 
INCOMING_PHYS ICAL.PACKETS 
OUTGOING_PHYS ICAL_PACKETS 
INCOMING_LINK_PACKETS 
OUTGOING_LINR_PACKETS 

SEE  ALIASES 
OVERVIEW  LAYER 


PRIMARY_OPERATOR_COMMANDS 

OPERATORJMMMANDS 

SEC0NDARY_0PERAT0RJ30MMANDS 

SEE  ALIASES 
OVERVIEW  LAYER 


PRIMARY_OPERATOR_DISPLAY 
OPERATORJ)ISPLAY 
SECONDARY_OPERATORJDI SPLAY 

PRI MARY_OPERA  TOR_DI S  PLAY  =  |  TRAN SPORT_DI S PLAY__COMMANDS  I 

I  HELP_RESPONSE  I 


OVERVIEW  LAYER 


DATA  ELEMENT  NAME 
ALIASES: 


PRIMARY_START_FILE_CONFIGURATION 

NONE 


VALUES  AND  MEANINGS 


NOTES: 

DATA  ELEMENT  NAME: 
ALIASES : 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES : 

VALUES  AND  MEANINGS: 

NOTES: 

DATA  FLOW  NAME: 
ALIASES : 

COMPOSITION: 

NOTES: 

DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES : 

DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 


REFER  TO  DATA  DICTIONARY  FOR  ARCHITECTURE  LEVEL  PROTOCOL. 
EXECUTE  ARICHITECTURE  LEVEL  PROTOCOL  LAYER 


PROTOCOL^ START_INFORMATION 
NONE 

A  FLAG  USED  TO  OBTAIN  STARTUP  PROCEDURES. 
EXECUTE  HELP  COMMANDS  LAYER 


RECEIVED_INCORRECT_PAS  SWORD  _COMMAND 
NONE 

REFER  TO  DATA  DICTIONARY  FOR  TRANSPORT/NETWORK  LEVEL 
PROTOCOL. 

EXECUTE  TRANSPORT  PROTOCOL  LAYER 


SECONDARY_INCOMING_PHYS  ICAL_PACKETS 

INCOMING_LINK_PACXETS 

PRI  MARY_INCOMING_PHYS  ICAL_PACKETS 

INCOMING_PHYS ICAL_PACKETS 

OUTGOING_PHYS  ICALJPACKETS 

OUTGOING_LINK_PACKETS 

SEE  ALIASES 
OVERVIEW  LAYER 


SECONDARY_OPERATOR_COMMANDS 

OPERATOILCOMMANDS 

PRIMARY.OPERATOR^COMMANDS 

SEE  ALIASES 
OVERVIEW  LAYER 


SECONDARY_OPERATORJ)ISPLAY 

PRIMARY_OPERATOR_DISPLAY 

OPERATORJJISPLAY 

SEE  ALIASES 
OVERVIEW  LAYER 
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DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


SOH_PACKET 

NONE 

REFER  TO  DATA  DICTIONARY  FOR  LINK  LEVEL  PROTOCOL. 
EXECUTE  LINK  LEVEL  PROTOCOL  LAYER 


STARTUP_PROCEDURES 

NONE 

STARTUP_PROCEDURES  =  A  TABLE  THAT  CONTAINS  ALL  COMMANDS 

AND  ACTIONS  OF  A  NETWORK  STARTUP. 
EXECUTE  HELP  COMMANDS  LAYER 


SYNC 

NONE 

REFER  TO  DATA  DICTIONARY  FOR  LINK  LEVEL  PROTOCOL. 
EXECUTE  LINK  LEVEL  PROTOCOL  LAYER 


TRAN  SPO  RT_J)I  S  PLAY jCOMMANDS 
NONE 

TRANSPORTJ)ISPLAY_COMMANDS  = 

T" RECE  IVED_INCORRECT_PAS  SWORD_COMMAND  I 
I  ERRORjtEASON  I 

I  FLOW_CONTRGL_ERRORS  I 

EXECUTE  NETWORK  PROTOCOL  AT  PRIMARY  NODE  LAYER 


TRAN  SPORT_OPERATION_COMMANDS 
NONE 

TRANSPORT_OPERATION_COMMANDS  = 


I  OPERATOR^PAS  SWORD_COMMAND 
I  OPERATOR_START_COMMAND 
I  ABORT.COMMAND 
I  DISCONNECT_REQUEST 
I  CONNECT_REQUEST 
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-.v  „„ 


FILE  DEFINITIONS  (P^ 

t 


FILE  OR  DATABASE  NAME:  DIALOGUE^ PROCES  S_TABLE 

ALIASES:  NONE 

COMPOSITION: 

REFER  TO  DATA  DICTIONARY  FOR  THE  TRANSPORT/NETWORK 
LEVEL  PROTOCOL. 

NOTES:  EXECUTE  HELP  COMMANDS  LAYER 
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PROCESS  NAME:  DETERMINE  COMMAND  TYPE 

PROCESS  NUMBER:  1.1 

PROCESS  DESCRIPTION: 

IF  USEIL.COMMAND  contains  NETWORK_ID  and  COMMAND_FIELD  =  TRAN SFER_COMMAND  then 
Output  command  as  ARCHITECTURE_OPERATION_COMMANDS 
ELSEIF  USEIL.COMMAND  contains  NETWORK_ID  and  C OMMAND_F I ELD  =  LOGICAL_LINK_ 
ESTABLISHMENT  then 

Output  command  as  TRAN SPORT_OPERATION_COMMANDS 
ELSEIF  USER_COMMAND  contains  NETWORK_ID  and  COMMAND_FIELD  =  HELP  then 
Output  command  as  NETWORK_HELP_COMMAND 
ELSE  output  command  as  LOCAL_COMMAND 


PROCESS  NAME:  .  DECODE  HELP  COMMAND 

PROCESS  NUMBER:  1.2.1 

PROCESS  DESCRIPTION: 

IF  NETWORK_HELP_COMMAND  contains  HELP_FIELD  =  General  information  then 
Output  GENERAL_INFORMATION  Flag 

ELSEIF  NETWORK_HELP_COMMAND  contains  HELP_FIELD  =  File  transfer  then 
Output  FILE_TRAN SFER_INFORMATION  Flag 
ELSEIF  NEIVORK_HELP_COMMAND  contains  HELP_FIELD  =  Start  then 
Output  PROTOCOL_START_INFORMATION 
ELSE  output  LIST_OF_ACTIVE_HOST_AND_DEVICE_NAMES  Flag 


PROCESS  NAME:  PROVIDE  GENERAL  NETWORK  INFO 

PROCESS  NUMBER:  1.2.2 

PROCESS  DESCRIPTION: 

IF  Input  =  GENERAL_INFORMATION  Flag  then 
Output  MENU_SELECT ION 
ELSE  Null 


PROCESS  NAME:  PROVIDE  PROCEDURE  FOR  TRANSFERING  FILES 

PROCESS  NUMBER:  1.2.3 

PROCESS  DESCRIPTION'; 

IF  Input  =  FILE_TRANSFEBL_INFORMATION  Flag  then 
Output  FILE_TRANSFER_PROCEDURE 
ELSE  Null 


PROCESS  NAME 


PROVIDE  LIST  OF  ACTIVE  HOSTS  AND  DEVICES 


PROCESS  NUMBER:  1.2.4 

PROCESS  DESCRIPTION: 

IF  Input  =  LI ST_OF_ACT IVE_RO ST_AND__DEV I CE_NAME S  Flag  then 


Extract  from  DIALOGUE_PROCESS_TABLE  and 
Output  NETWORK_CONFIGURATION 

ELSE  Null 


PROCESS  NAME:  PROVIDE  NETWORK 

PROCESS  NUMBER:  1.2.5 

PROCESS  DESCRIPTION: 

IF  Input  =  PROTOCOL_START_INFORMATION 
Output  STARTUP_PROCEDURES 
ELSE  Null 


STARTUP  PROCEDURES 
Flag  then 

1 


PROCESS  NAME:  CODE  HELP  RESPONSES 

PROCESS  NUMBER:  1.2.6 

PROCESS  DESCRIPTION: 

IF  Input  =  MENU_S ELECTION*  FILE_TRANSFER_PROCEDURES .  NETWORK_CONFIGURATION , 
or  STARTUP_PROCEDURES  then 

Output  as  HELP_RESPONSE 

ELSE  Null 


PROCESS  NAME:  EXECUTE  ARCHITECTURE  LEVEL  PROTOCOL 

PROCESS  NUMBER:  1.3 

PROCESS  DESCRIPTION: 

EXECUTE  the  necessary  processes  to  provide  standardized  formats  and  procedures 
for  accessing  and  passing  data  between  a  user  process  and  a  file  system 
existing  in  a  network  enviroment. 


PROCESS  NAME:  EXECUTE  TRANSPORT  LEVEL  PROTOCOL 

PROCESS  NUMBER:  1.4 

PROCESS  DESCRIPTION: 

EXECUTE  the  necessary  processes  to  create  an  interprocess  communication 
mechanism  amoung  the  network  nodes.  It  is  concerned  with  the  set  of 
services  provided  and  management  within  the  network. 


PROCESS  NAME:  EXECUTE  NETWORK  LEVEL  PROTOCOL 

PROCESS  NUMBER:  1.5 

PROCESS  DESCRIPTION: 

EXECUTE  the  processes  necessary  to  control  the  routing  of  packets  within  the 
communication  network. 
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PROCESS  NAME:  EXECUTE  LINK  LEVEL  PROTOCOL 

PROCESS  NUMBER:  1.6 

PROCESS  DESCRIPTION: 

EXECUTE  the  processes  necessary  to  provide  a  data  link  control  procedure  that 

will  ensure  a  reliable  data  communication  path  between  nodes  of  an  network. 


PROCESS  NAME: 

PROCESS  NUMBER: 
PROCESS  DESCRIPTION: 
EXECUTE  the  interface 
to  another. 


EXECUTE  PHYSICAL  LEVEL  PROTOCOL 
1.7 


processes  necessary  to  deliver  a  bit  stream  from  one  node 


PROCESS  NAME:  DECODE  PROTOCOL  RESPONSES 

PROCESS  NUMBER:  1.8 

PROCESS  DESCRIPTION: 

DELIVER  individual  TRANSPORT_DISPLAY_COMMANDS  to  the  operator  as 
OPERATOR_DISPLAY 


PROCESS  NAME:  EXECUTE  EWNET  PROTOCOL  AT  SECONDARY  NODE 

PROCESS  NUMBER:  2.0 

PROCESS  DESCRIPTION: 

EXECUTE  the  architecture  protocol,  transport  protocol,  network  protocol,  link 
protocol,  and  physical  protocol  established  for  tne  EWNET. 
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I 


DATA  DICTIOHARY 

FOR  THE  ARCHITECTURE  LEVEL  (A)  PROTOCOL 


Contents 

Data  Element  /  Flow  Descriptions . . 

File  Definitions . 

Process  Specification . . 


Page 

191 

239 

240 


DATA__FLOW_NAME : 

ALIASES: 

COMPOSITION: 


ABORT/ STATU S_ERRORS 
NONE 

ABORT/ST ATUS_ERRORS  =  I  RECEIVED_UNSUPPORT_STATUS2 

I  RECEIVED_FO RMAT_ST ATU S 2 
I  RECEIVED_SYNC_STATUS2 
f  R  EC  E I V ED_U NS UP  PO  RT_MI S C 
I  RECEIVED_FORMAT_MISC 
I  RECEIVED_SYNC_UNKNOWN 


NOTES : 


EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 


DATA  FLOW  NAME:  ACC/ECF/SCF_PACKET 

ALIASES:  NONE 

COMPOSITION:  _  _ 

ACC/ECF / SCF_PACKET  =  I  ACCESS(ECF)  JPACKET  I 

I  ACCESS(SCF)_PACKET  I 

NOTES:  EXECUTE  STARTUP  PACKETS  LAYER 


DATA  ELEMENT  NAME:  ACCEPT_CONFIRM 
ALIASES:  NONE 

VALDES  AND  MEANINGS: 

A  FLAG  FROM  THE  TRANSPORT  PROTOCOL  IMPLYING  THAT  THE 
CONNECT_CONFIRM  PACKET  HAS  BEEN  RECEIVED  AND  THE  LOGICAL. 
LINK  ESTABLISHED. 

NOTES:  EXECUTE  STARTUP  PACKETS  LAYER, 

EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 


DATA  FLOW  NAME:  ACC/ERWPACKET 

ALIASES :  NONE 

COMPOSITION:  _  _ 

ACC/ERJPACKET  =  I  ACCESS(ERASE)_PACKET  I 
!  AC  CES  S ( RENAKE )_PACKET | 


NOTES: 


EXECUTE  STARTUP  PACKETS  LAYER 


DATA  FLOW  NAME:  ACCESS_COMPLETE_PACKET 

ALIASES :  RECEIVED  JlCCESS_COMPLETE_PACKET 

VALID_RECEIVED_AC  CES  S_COMPLETE_PACKET 
RECEIVED  _^AC  COMP ( COMMAND ) 

RECEIVED  _J£  COMP ( PURGE ) 
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COMPOSITION: 
NOTES : 

DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 
NOTES : 

DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 
NOTES : 

DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 

DATA  FLOW  NAME: 


RECEIVED_ACCOMP( RESPONSE) 

RECEIVED_AC COMP (EOS) 

ACCESS_COMPLETE_PACKET  =  OPERATOR  +  TYPE=7  +  CMPFUNC  +  FOP 
EXECUTE  STARTUP  PACKETS  LAYER 
EXECUTE  ACC/ACK  PACKETS  LAYER 


accessCecf )_packet 

ACCES  S_PACKET 

AC  CE  S  S  (  E  RAS  E )  _PACKE  T 

AC  CE  S  S ( RENAME ) _PACKE  T 

ACCESS( SCF)_PACKET 

RECEI VED_AC  CE  S  S_PACKET 

valid.rece IVEDjVC CES S_PACKET 

SEE  ALIASES 

EXECUTE  STARTUP  PACKETS  LAYER 


ACCES  S ( ERAS  E )  .PACKET 

ACCES S.PACKET 

AC  CES  S ( RENAME ) .PACKET 

AC  CE  S  S ( ECF )  _PACKE  T 

AC  CES  S ( SCF )  .PACKET 

RECEIVED_ACCESS_PACKET 

V  AL ID.RECE I V ED_AC  CE S  S.PACKE T 

SEE  ALIASES 

EXECUTE  STARTUP  PACKETS  LAYER 


ACCES S.PACKET 

RECE I VED  JVC  CE  S  S.PACKE  T 

VAL  ID.RECE  I  VED_,AC  CES  S.PACKE  T 

AC CES S( ERASE )_?ACKET 

AC  CES  S ( RENAME )  .PACKET 

ACCESS(ECF) .packe  t 

ACCESS( SCF )_PACKET 

ACCESS.PACKET  =  OPERATOR  +  TYPE=3  +  ACCFUNC  +  ACCOPT  + 
FILESPEC  +  FAC  +  SHR 
EXECUTE  STARTUP  PACKETS  LAYER 
EXECUTE  ACC/ACK  PACKETS  LAYER 


ACCESS (RENAME )JPACKET 
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ALIASES: 


COMPOSITION: 
NOTES : 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES : 

VALDES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 


ACCES  S_PACKET 

AC CESS ( ERASE )J?ACKET 

ACCESS(SCF)_PACKET 

ACCESS(ECF)_PACKET 

RECE IVED_AC  CE  S  S_PACKE . 

VALID_RECE IVED  JVCCES  S.PACKET 

SEE  ALIASES 

EXECDTE  STARTUP  PACKETS  LAYER 


AC CESS(SCF) .PACKET 
ACCESS.PACKET 
AC CESS (ERASE)  ^PACKET 
ACCES  S( RENAME )  .JACKET 
ACCESS(ECF) _PACKE  T 
RECEIVED  JVC CE  S  S.PACKE  T 
VAL ID.RECE I VED  JVC  CE  S  S.PACKE  T 

SEE  ALIASES 

EXECDTE  STARTDP  PACKETS  LAYER 


ACCFDNC 

NONE 

THE  REQDEST  CODE  SPECIFYING  THE  OPERATION  TO  BE  PERFORMED 
SDCH  AS:  OPEN  FILE,  CREATE  FILE,  RENAME  FILE,  ERASE 

FILE,  DIRECTORY  LIST,  SDBMIT  AS  COMMAND  FILE,  AND  EXECDTE 
COMMAND  FILE. 

ALL  ARCHITECTURE  LAYERS 


ACCOMP( COMMAND) 

ACCOMP(PDRGE) 

A  FLAG  USED  TO  INDICATE  THE  END  OF  A  DATA  STREAM,  PLUS  A 
POSSIBLE  ABORT,  PLUS  THE  REQUESTING  OF  THE  END  OF  THE 
LOGICAL  LINK.  GENERATES  THE  APPROPRIATE  ACCESS_COMPLETE_ 
PACKET 

EXECUTE  ACC/ACK  PACKETS  LAYER 
EXECDTE  CONTINUE  PACKETS  LAYER 

EXECDTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 


ACCOMP(EOS) 

NONE 
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VALUES  AND  MEANINGS 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


A  FLAG  USED  TO  INDICATE  THE  END  OF  A  DATA  STREAM  REQUEST. 
GENERATES  AN  ACCESS_COMPLETE_PACKET. 

EXECUTE  ACC/ACK  PACKETS  LAYER 
EXECUTE  CONTINUE  PACKETS  LAYER 

EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 


ACCOMP(PURGE) 

ACCOMP( COMMAND) 

SEE  ALIASES 

EXECUTE  ACC/ACK  PACKETS  LAYER 
EXECUTE  CONTINUE  PACKETS  LAYER 

EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 


AC COPT 

NONE 

ACCESS  OPTIONS: 

1.  A  RECORD  MAY  BE  SKIPPED  OR  REPEATED  AS  SPECIFIED  BY 
THE  CONTINUE  PACKET.  I/O  ERRORS  ARE  NOT  FATAL. 

2.  IF  SET,  A  STATUS  PACKET  WILL  BE  RETURNED  FOLLOWING 
EACH  RECORD  SENT  TO  THE  ACCESSED  PROCESS  IN  THE 
RECORD  ACCESS  MODE. 

3.  IF  SET,  RETURN  A  STATUS  PACKET  WITH  EACH  RECORD 
RETRIEVED  FROM  AN  ACCESSED  SYSTEM.  THE  STATUS 
PACKET  SHOULD  PRECEDE  THE  DATA  PACKET  SO  THAT  IT  IS 
POSSIBLE  TO  BLOCK  THE  TWO  INTO  ONE  PACKET.  WHEN  A 
USER  REQUIRES  A  RECORD  FILE  ADDRESS  TO  BE  RETURNED, 
THIS  OPTION  IS  USED. 

ALL  ARCHITECTURE  LAYERS 


ACKNOWLEDGE_PACKET 

VALID_RECEIVED_ACKNOWLEDGE_PACKET 

RECEIVED_ACKNOWLEDGE_PACKET 

ACKNOWLEDGE_PACKET  =  OPERATOR  +  TYPE=6 
EXECUTE  ACC/ACK  PACKETS  LAYER 
EXECUTE  STARTUP  PACKETS  LAYER 


ADD_GET_PACKET 
RECEIVED  JiDD_GET_PACKET 
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NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES : 


ADD_GET_PACRET  =  OPERATOR  +  TYPE=4  +  CTLFUNC  +  CTLMENU  + 
RAC  +  KEY  +  ROP 

GENERATE  CONTROL  PACKETS  LAYER 


ADD_PUT_PACRE  T 
RECEIVED_ADD_PUT_PACKET 

ADD_PUT_PACKE  T  =  OPERATOR  +  TYPE=4  +  CTLFUNC  +  CTLMENU  + 
RAC  +  KEY  +  ROP 

GENERATE  CONTROL  PACKETS  LAYER 


ALQ 

NONE 

THIS  FIELD  SPECIFIES  THE  ALLOCATION  QUANTITY.  FOR  FILE 
CREATION,  IT  SPECIFIES  THE  INITIAL  SIZE  OF  THE  NEW  FILE. 
THE  ACTUAL  SIZE  OF  THE  NEW  FILE  IS  RETURNED  IN  THIS  FIELD. 
ALL  ARCHITECTURE  LAYERS 


ATTMENU 

NONE 

SPECIFIES  WHICH  OF  THE  ATTRIBUTES  FIELDS  WILL  BE  PRESENT  IN 
THE  MAIN  ATTRIBUTES  PACKET. 

ALL  ARCHITECTURE  IAYERS 


ATTRI B/AC  C_ERROR 
NONE 

A  FLAG  USED  TO  NOTIFY  THE  ACCESS  CHECK  PROCESS  THAT  ON  A 
RECEIVE  OF  A  ATTRIB/AC CJPACKET  THE  ATTRIBUTES  PORTION  OF 
THE  PACKET  WAS  IN  ERROR. 

EXECUTE  STARTUP  PACKETS  LAYER 


ATTRI B/AC  C_PACKET 
RECEIVED  JUTTRIB/AC  C_PACKET 

ATTRIB/AC C_PACKET  =  ATTRIBUTES_PACKET  +  ACCESS_PACKET 
EXECUTE  STARTUP  PACKETS  LAYER 
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DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES : 


DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES : 

VALUES  AND  MEANINGS: 
NOTES : 


ATTRIB/ACK_ERROR 

NONE 

A  FLAG  USED  TO  NOTIFY  THE  ACKNOWLEDGE  CHECK  PROCESS  THAT 
ON  A  RECEIVE  OF  A  ATTRIB/ ACK_PACF.ET  THE  ATTRIBUTES  PORTION 
OF  THE  PACKET  WAS  IN  ERROR. 

EXECUTE  STARTUP  PACKETS  LAYER 


ATTRIB / ACK_PACKE  T 

RECE I VED_ATTRI B/ACK_PACKE  T 

ATTRI B/ ACK_PACKE  T  =  ATTRIBUTES_PACKET  +  ACKNOWLEDGE_PACKET 
EXECUTE  STARTUP  PACKETS  LAYER 
EXECUTE  ACC/ACK  PACKETS  LAYER 


ATTRIBUTES.PACKET 

RECE IVED_ATTRI BUTES_PACKE  T 

VAL ID_RECE IVED_ATTRI BUTES_PACKET 

ATTRIBUTES_PACKET  =  OPERATOR  +  TYPE =2  +  ATTMENU  + 

(DATATYPE)  +  (ORG)  +  (RFM)  +  (RAT)  + 
(BLS)  +  (MRS)  +  (ALQ)  +  (BKS)  +  (FSZ)  + 
(MRN)  +  (RUNSYS)  +  (DEQ)  +  (FOP) 

EXECUTE  STARTUP  PACKETS  LAYER 


BKS 

NONE 

BUCKET  SIZE.  USED  ONLY  FOR  ACCESS  TO  RELATIVE  FILES. 
ALL  ARCHITECTURE  LAYERS 


BLS 

NONE 

PHYSICAL  BLOCK  SIZE. 

ALL  ARCHITECTURE  LAYERS 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS 


BUFSIZE 

NONE 


’T3 


THE  MAXIMUM  BUFFER  SIZE  OF  THE  SENDING  SYSTEM  ALLOCATED  FOR 
PACKET  EXCHANGE.  THE  TWO  SPEAKING  PROCESSES  WILL  USE  THE 
LESSER  OF  THE  TWO  BUFFER  SIZES  AS  THE  MAXIMUM  SIZE.  IF  A 
SYSTEM  HAS  AN  UNLIMITED  BUFFER  SIZE.  IF  SENDS  A  0  AND  THE 
TWO  SYSTEMS  WILL  USE  THE  NONZERO  BUFFER  SIZE  AS  THE  MAXIMUM. 
NOTES:  ALL  ARCHITECTURE  LAYERS 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


CMPFUNC 

NONE 

ACCESS  COMPLETION  FUNCTIONS  SUCH  AS: 

1.  TERMINATE  ACCESS 

2.  RESPONSE 

3 .  PURGE 

4.  END_OF_STREAM  (EOS) 
ALL  ARCHITECTURE  LAYERS 


DATA  FLOW  NAME: 
ALIASES : 

COMPOSITION: 


NOTES: 


CONFIGURATION_PACKET 

RECEIVED_CONFIGURATION_PACKET 

VALID_RECEIVED_CONFIGURATION_PACKET 

CONFIGURATION_PACKET  =  OPERATOR  +  TYPE=1  +  BUFSIZE  + 

OSTYPE  +  FILESYS  +  VERSION  +  SYSCAP 
EXECUTE  STARTUP  PACKETS  LAYER 


DATA  ELEMENT  NAME:  CONFUNC 

ALIASES :  NONE 

VALUES  AND  MEANINGS: 

THIS  FIELD  IS  USED  TO  SPECIFY  THE  RECOVERY  ACTION  TO  BE 
TAKEN.  1.  TRY  AGAIN 

2.  SKIP 

3.  ABORT 

NOTES:  ALL  ARCHITECTURE  LAYERS 


DATA  FLOW  NAME:  CONNECT_PACKET 

ALIASES :  RECEIVED_CONNECT_PACKET 

COMPOSITION: 

CONNECT_PACKET  =  OPERATOR  +  TYPE=4  +  CTLFUNC  +  (CTLMENU)  + 
(RAC)  +  (KEY)  +  (ROP) 

NOTES:  GENERATE  CONTROL  PACKETS  LAYER 
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DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 


NOTES: 


DATA  FLOW  NAME: 
ALIASES : 


COMPOSITION: 

NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


CONT INOE_ABORT_ERROR 
CONT  INUE_SK  I  P_ERROR 
CONT  INUE_ONLY_ERROR 

CONT INUE_ABORT_ERROR  =  TrECEIVED_UNSDPPORT_CONTINDE~7 

I  RECE I V  ED_FO  RMAT_CONT  INTIE  | 

I  RECE IVED_SYNC_CONT INUE  I 

EXECUTE  CONTINUE  PACKETS  LAYER 


CONTINUE_ABORT_PACKET 
CONTINUE_ONLY_PACKET 
CONTINUE_SKIP_PACKET 
RECEIVED_CONT INUE _ABORT_PACKET 
RECE I VED_CONT INUE_0NLY_ PACKET 
RECEIVED__CONT  INUE_SKIP_PACKET 

SEE  ALIASES 

EXECUTE  CONTINUE  PACKETS  LAYER 


CONTINUE/DATAJPACKET 

NONE 

CONTINUE/DATAJPACKET  =  CONTINUE_INTERRUPT_PACKET  +  DATA_ 

PACKET 

EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 


CONT INUE_ERRORS 
NONE 

CONT INUE_ERRORS  =  T 1 RECEIVED_UNSUPPORT_CONTINUE  I 
I  RECE IVED_FORMAT_CONT INUE  I 

I  RECE I VED_SYNC_CONT INUE  I 

I  RECE IVED_UNSUPPORTJMISC  ! 

I  RECE IVED_FORMATJMISC  I 

I  RECE IVED_SYNC_UNKNOWN  I 

EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 
CODE  ARCHITECTURE  PACKETS  LAYER 


CONTINUE_INTERRDPT_PACKET 

RECEIVED_CONTINUE_PACKETS 


«  * 

* 

*  ► 
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NOTES: 

DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 

DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 

DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 

DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 

DATA  ELEMENT  NAME: 


CONTINUE_INTERRDPT_PACKET  =  CONT INUE_ABORT_PACKET  + 

CONT INUE_SKI P_PACKET  + 
CONT INUE_ONLY_PACKE  T 
EXECUTE  CONTINUE  PACKETS  LAYER 
CODE  ARCHITECTURE  PACKETS  LAYER 


CONT INUE_ONLY_ERROR 
CONT INUE_ABORT_ERROR 
CONT INUE_SKI P_ERROR 

SEE  ALIASES 

EXECUTE  CONTINUE  PACKETS  LAYER 


CONTINUE_ONLY_PACKET 

continue_abort_packet 

CONT INUE_SKI P_PACKET 
RECEIVED_CONTINUE_ABORT_PACKET 
RECE IVED_CONT INUE_SRI  P_J»ACKET 
RECEIVED_CONTINUE_ONLY_PACKET 

CONT INUE_ONLY_PACKET  =  OPERATOR  +  TYPE =5  +  CONFUNC 
EXECUTE  CONTINUE  PACKETS  LAYER 


CONT INUE_SKI P_ERROR 

continue_abort_error 

CONTINUE_ONLY_ERROR 
SEE  ALIASES 

EXECUTE  CONTINUE  PACKETS  LAYER 


CONTINUE_SKIP_PACKET 
CONT INUE_ONLY_PACKET 

continue_abort_packet 

RECE I VED_CONT INUE _ABORT_PACKE T 
RECE I VED_CONT INUE_ONLY_PACKE T 
RECEIVED_CONTINUE_SKIP_PACKET 

SEE  ALIASES 

EXECUTE  CONTINUE  PACKETS  LAYER 


CONT INUE_WI TH_BAD_R ECO  RD 
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ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


NONE 

A  FLAG  USED  TO  INDICATE  THAT  THE  BAD  RECORD  SHOULD  BE  LEFT 
AS  IS  AND  CONTINUE  RECIEVING  RECORDS. 

EXECUTE  CONTINUE  PACKETS  LAYER 


CONTROL_PACKET 

RECEIVED_CONTROL_PACKET 

CONTROL_PACKET  =  T~ CONNECT_PACKET~ 

I  GET_PACKET  I 

I  PUT_PACKET  I 

GENERATE  CONTROL  PACKETS  LAYER 
CODE  ARCHITECTURE  PACKETS  LAYER 

EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 


CTLFUNC 

NONE 


SPECIFIC  CONTROL  INFORMATION: 

1 .  GET  RECORD 

2.  CONNECT 

3 .  UPDATE 

4.  PUT  RECORD 

5.  DELETE 

6 .  REWIND 

ALL  ARCHITECTURE  LAYERS 


CTLMENU 

NONE 

INDICATES  OPTIONAL  FIELDS  ARE  PRESENT. 
ALL  ARCHITECTURE  LAYERS 


DATA 

FILEJJATA 

THE  FILE  DATA  BEING  TRANSFERRED.  THIS  FIELD  IS  TOTALLY 
TRANSPARENT  AND  USES  ALL  8-BITS  OF  EACH  BYTE. 

EXECUTE  CONTINUE  PACKETS  LAYER 
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DATA  FLOW  NAME; 

ALIASES: 

COMPOSITION; 


NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES : 

VALUES  AND  MEANINGS: 


DATAJSRRORS 

NONE 

DATA^ERRORS  =  T~ RECEIVED_UNSUPPORT_DATA 
I  RECE I VED_FORMAT_DA  TA 
I  RECE I  VED_SYNC_DATA 
I  RECEIVED_ONSUPPORT_MISC 
I  RECE IVED_FORMAT_MISC 
I  RECEIVED_SYNC_DNKNOWN 

EXECUTE  CONTINUE  PACKETS  LAYER 
CODE  ARCHITECTURE  PACKETS  LAYER 


DATA_PACKET 

RECEIVED_DATA_FILE 

DATA^PACKET  =  OPERATOR  +  TYPE =8  +  RECNUM  +  FILEDATA 
EXECUTE  CONTINUE  PACKETS  LAYER 
CODE  ARCHITECTURE  PACKETS  LAYER 


DATAJTYPE 

NONE 

THE  TYPE  OF  DATA  BEING  TRANSFERRED.  DEFAULT  TO  IMAGE. 

THIS  FIELD  IS  VERY  IMPORTANT  FOR  FILE/RECORD  RETRIEVAL. 
MANY  FILE  SYSTEMS  DO  NOT  EXPLICITLY  STORE  WITH  THE  FILE 
ATTRIBUTES,  INFORMATION  AS  TO  WHETHER  THE  FILE  CONTAINS 
ASCII.  EBCDIC,  OR  IMAGE  DATA.  THEREFORE,  THE  CONTENTS 
OF  A  FILE  ARE  INTERPRETED  ACCORDING  TO  THE  DATA  TYPE 
SUPPLIED  BY  THE  USER. 

IMAGE  IS  THE  MODE  WHERE  NO  CODE  SET  IS  SPECIFIED.  IT  IS  A 
FORMAT  FOR  SENDING  8-BIT  QUANTITIES  WITHOUT  SPECIFYING  ANY 
CODE  REPRESENTATION.  THE  ACTUAL  DATA  MAY  BE  ASCII,  OR 
BINARY.  IT  IS  UP  TO  THE  USER  PROCESS  TO  DETERMINE  HOW  TO 
USE  THE  DATA. 

ALL  ARCHITECTURE  LAYERS 


DEQ 

NONE 

FILE  EXTENSION  QUANTUM  SIZE  IN  VIRTUAL  BLOCKS,  WHICH  IS  TH 
AMOUNT  OF  SPACE,  IN  BLOCKS,  ADDED  TO  THE  FILE  EACH  TIME  TH 
FILE  IS  IMPLICITLY  EXTENDED. 

ALL  ARCHITECTURE  LAYERS 


NOTES 


IT.  M 


t 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS 


DISCONNECT 

NONE 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 


A  FLAG  USED  TO  INDICATE  TERMINATION  OF  THE  LOGICAL  LINK. 
CODE  ARCHITECTURE  PACKETS  LAYER 


DISCONNECT_REQUEST 

NONE 

REFER  TO  DATA  DICTIONARY  FOR  TRAN SPORT/ NETWORK  LEVEL 
PROTOCOL. 

CODE  ARCHITECTURE  PACKETS  LAYER 


EOF 

RECEIVED_EOF 
SEE  ALIASES 

EXECUTE  CONTINUE  PACKETS  LAYER 
CODE  ARCHITECTURE  PACKETS  LAYER 


EXECUTEJERRORS 

NONE 

EXECUTE_ERRORS  =  7"<)PERATION_IN_PROGRESS  | 

I  FILE_ERRORS  I 

I  SUCCESSFUL_OPERATION  I 

I  EOF  I 

I  DATA_ERRORS  I 

EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 


NONE 

FILE  ACCESS  OPERATIONS  A  USER  REQUIRES. 
ALL  ARCHITECTURE  LAYERS 


i : 


FLAGS 
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ALIASES: 

VALUES  AMD  MEANINGS: 


MOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES : 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


NONE 

THE  PACKET  FLAGS  SUCH  AS: 

1.  STREAM  IDENTIFICATION  FIELD  PRESENT 

2.  LENGTH  FIELD  PRESENT 

3.  EXTENSION  PRESENT 
ALL  ARCHITECTURE  LAYERS 


FILE_DATA 

DATA 

SEE  ALIASES 

ALL  ARCHITECTURE  LAYERS 


FILE_ERRORS 

RECEIVED_FILE_ERRORS 

SEE  ALIASES 

EXECUTE  CONTINUE  PACKETS  LAYER 
CODE  ARCHITECTURE  PACKETS  LAYER 


FILESPEC 

NONE 

THE  FILE  SPECIFICATION  IN  THE  FORMAT  REQUIRED  BY  THE 
REMOTE  NODE. 

ALL  ARCHITECTURE  LAYERS 


FILESYS 

NONE 

FILE  SYSTEM  TYPE  OF  THE  FILE  SYSTEM  BEING  USED  BY  THE 
PROCESS  SENDING  THIS  MESSAGE. 

ALL  ARCHITECTURE  LAYERS 


FIRST_ATTRIB_FLAG 

NONE 

A  FLAG  SET  WHEN  THIS  NODE  IS  THE  ONE  GENERATING  THE  FIRST 
ATTRIBUTES  PACKET. 

EXECUTE  STARTUP  PACKETS  LAYER 
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DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


FIRST_CONFIG_FLAG 

NONE 

A  FLAG  SET  WHEN  THIS  NODE  IS  THE  ONE  GENERATING  THE  FIRST 
CONFIGURATION_PACKET. 

EXECUTE  STARTUP  PACKETS  LAYER 


FOP 

NONE 


FILE  ACCESS  OPTIONS  A  USER  REQUIRES  SUCH  AS  REWIND,  OPEN, 
REWIND  ON  CLOSE,  OR  POSITION  MAGNETIC  TAPE,  ETC. 

ALL  ARCHITECTURE  LAYERS 


FSZ 

NONE 

SIZE  OF  THE  FIXED  PART  OF  VARIABLE  LENGTH  RECORDS  WITH 
FIXED  CONTROL  FORMAT. 

ALL  ARCHITECTURE  LAYERS 


GET_PACKET 

RECE IVED_GET_PACKE  T 

GET_PACKET  =  T ADD_GET_PACKET~~ [ 
I  KEY_GET_PACKET  I 
I  SEQ_GET_PACKET  | 

GENERATE  CONTROL  PACKETS  LAYER 


INCOMING_PRIMARY_NODE_ARCHITECTUKE_PACKETS 

INCOMING_SECONDARY_NODE-ARCHITECTURE_PACKETS 

INCOMING_PRIMARY_NODE_ARCHITECTURE_PACKETS  = 

I  RECE IVED_AC  CE  S  S_COMPLETE_PACKET  I 

I  RECE I VED_STATU S_PACKET  I 

I  RECEIVED_STARTUP_PACKET  I 

I  RECEIVED.CONTINUEJVBORT  I 
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I  ACCEPT_CONFIRM 
I  RECEIVED_CONTINUE_ONLY_?ACKET 
I  RECE I V  ED_CONT INUE_SK I P_PACKE T 
I  RECEIVED_DATA_FILE 
I  RECEIVED_CONTROL_FILE 
I  DISCONNECT_CONFIRM_VERSION 

NOTES:  EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 

OVERVIEW  LAYER 


DATA  FLOW  NAME:  INCOMING_SECONDARY_NODE _ARCHITECTURE_PACKETS 

ALIASES:  INCOMING_PRIMARY_HODE _ARCHITECTURE_PACKETS 

COMPOSITION: 

SEE  ALIASES 

NOTES:  OVERVIEW  LAYER 


DATA  ELEMENT  NAME:  KEY 

ALIASES:  NONE 

VALUES  AND  MEANINGS: 

RELATIVE  FILES  =  RECORD  NUMBER 

INDEXED  FILES  =  RECORD  KEY 

DIRECT  FILES  =  RECORD  KEY 

RECORD  FILE  ADDRESS: 

ACCESS  MODE  =  RECORD  FILE  ADDRESS 

BLOCK  MODE  ACC  =  VIRTUAL  BLOCK  NUMBER 
ALL  ARCHITECTURE  LAYERS 


KEY_GET_PACKET 
RECEIVED  JCEY_GET_PACKET 

KEY_GET_PACKET  =  OPERATOR  +  TYPE=4  +  CTLFUNC  +  CTLMENU  + 
RAC  +  KEY  +  ROP 

GENERATE  CONTROL  PACKETS  LAYER 


NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES : 


DATA  FLOW  NAME:  KEY_PUT_PACKET 

ALIASES :  RECEIVED _REY_PUT_PACKET 

COMPOSITION: 

KEY_PUT_PACKET  =  OPERATOR  +  TYPE=4  +  CTLFUNC  +  CTLMENU  + 
RAC  +  KEY  +  ROP 

NOTES:  GENERATE  CONTROL  PACKETS  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


LENGTH 

NONE 

DENOTES  THE  LENGTH  OF  THE  OPERAND  FIELD  (NUMBER  OF  8-BIT 
BYTES) . 

ALL  ARCHITECTURE  LAYERS 


MRN 

NONE 

MAXIMUM  RECORD  NUMBER  FOR  A  FILE. 
ALL  ARCHITECTURE  LAYERS 


MRS 

NONE 

THE  LENGTH  OF  EACH  FILE  RECORD  IN  NUMBER  OF  BYTES.  FOR 
VARIABLEJLENGTH  RECORDS,  THIS  FIELD  SPECIFIES  THE  MAXIMUM 
RECORD  SIZE.  WHEN  THE  ACCESSED  PROCESS  RECEIVES  THE  MRS 
(MAXIMUM  RECORD  SIZE),  IT  MUST  CHECK  IT  AGAINST;  THE  LENGTH 
OF  ITS  BUFFER.  IF  THE  BUFFER  WILL  NOT  ACCOMMODATE  THIS 
SIZE  RECORD,  THE  ACCESSED  PROCESS  SHOULD  RETURN  ITS  BUFFER 
SIZE. 

ALL  ARCHITECTURE  LAYERS 


NEW  ^ACCESS 
NONE 

A  INTERNAL  FLAG  USED  TO  START  A  NEW  DATA  STREAM  ACCESS  ONCE 
AN  OLD  FILE  TRANSFER  IS  COMPLETE. 

EXECUTE  STARTUP  PACKETS  LAYER 
CODE  ARCHITECTURE  PACKETS  LAYER 

EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 


OPERAND 

NONE 

THE  INFORMATION  FIELD  OF  THE  PACKET.  IT  IS  DEPENDENT  ON  THE 
TYPE  FIELD. 

ALL  ARCHITECTURE  LAYERS 
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DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES : 


DATA  FLOW  NAME: 
ALIASES: 


OPERATION_IN_PROGRESS 
RECEIVED^ PENDING_STATUS 
RECE IVED_OPERATION_IN_PROG RES S 

SEE  ALIASES 

EXECUTE  CONTINUE  PACKETS  LAYER 
CODE  ARCHITECTURE  PACKETS  LAYER 


OPERATOR 

NONE 

OPERATOR  =  TYPE  +  FLAGS  +  (STREAMID)  +  (LENGTH)  +  (OPERAND) 
ALL  ARCHITECTURE  LAYERS 


ORG 

NONE 

ATTRIBUTES  OF  THE  FILE  BEING  ACCESSED.  DEFAULT  =  SEQUENTIAL. 
ALL  ARCHITECTURE  LAYERS 


OSTYPE 

NONE 

OPERATING  SYSTEM  TYPE 
ALL  ARCHITECTURE  LAYERS 


OUTGOING_PRIMARY_NODE_ARCHITECTURE_PACKETS 

OUTGOING_SECONDARY_NODE_ARCHITECTURE_PACKETS 

OUTGOING_PRIMARY_NODE_ARCHITECTURE_PACKETS  = 

I  DISCONNECT_REQUEST  I 
I  WORKING_PACKETS  I 
I  STATU S_PACKETS  I 


OVERVIEW  LAYER 

EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 
CODE  ARCHITECTURE  PACKETS  LAYER 


OUTGOING_SECONDARY_NODE— ARCHITECTURE_PACKETS 
OUTGOING_PRIMARY_NODE— ARCHITECTURE_PACKETS 


4.A 


COMPOSITION: 
NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


SEE  ALIASES 
OVERVIEW  LAYER 


PRIMARY_INCOMING_DIALOGUE_COMKANDS 

SECONDARY_INCOMING_DIALOGUE_COMMANDS 


PRIMARY_INCOMINGJ)IALOGUE_COMMANDS  = 

I  OPERATOR_PAS  SWORD_COMMAND~[ 
I  OPERATOR_START_COMMAND  I 
I  ABORT_COMMAND  I 
I  CONNECT_REQOEST  I 


OVERVIEW  LAYER 


PRIMARY_START_FILE_CONFIGURATION 

SECONDARY_START_FILE_CONFIGURATION 

THIS  IS  A  COMMAND  FROM  THE  OPERATOR  TO  START  THE  FILE. 
TRANSFER  PROTOCOL  BY  ISSUING  A  CONFIGURATION_PACKET. 
OVERVIEW  LAYER 

EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 
EXECUTE  STARTUP  PACKETS  LAYER 


PRIMARY_OUTGOING_DIALOGUE_COMMANDS 

SECONDARY_OUTGOING_DIALOGUE_COMMANDS 

PRIMARY_OUTGOING_DIALOGUE_COMMANDS  = 

I  RECE I VED_INCORRECT_PAS  SWORD_COMMAND  I 

I  FLOW_CONTRQL_ERRORS  I 

I  OUTGOING^ DIALOGUE_DATA_PACKET  I 

I  ERROR_REASON  I 

=  OUTGOING_DIALOGUE_MESSAGE 
REFER  TO  DATA  DICTIONARY  FOR  TRANSPORT/NETWORK  LEVEL 
PROTOCOL. 

OVERVIEW  LAYER 


PURGE/ABORT_INTERRUPT 

NONE 
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NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


A  FLAG  DSED  TO  INDICATE  THAT  A  CONTINDE_ABORT_PACKET  SHOULD 
BE  GENERATED  AND  ODTPDTED  AFTER  THE  GENERATION  OF  AN 
AC  COMP ( PDRGE ) _RACKET  OR  AC COMP (COMMAND) JACKET. 

EXECDTE  CONTINDE  PACKETS  LAYER 


PDT_PACKET 

RECEIVED_PUT_PACKET 

PDT_PACKET  =  |  SEQ_PUT_PACKET~ 
I  KEY_PDT_PACKET  | 

I  AD  D_PDT_PACKET  I 

GENERATE  CONTROL  PACKETS  LAYER 


RAC 

NONE 

SETS  THE  ACCESS  MODE: 

1.  SEQDENTIAL  RECORD  ADDESS 

2.  KEYED  ACCESS 

3.  ACCESS  BY  RECORD  FILE  ADDRESS 

4.  SEQDENTIAL  FILE  ACCESS 

5.  ACCESS  BY  VIRTDAL  BLOCK  NDMBER 

6.  BLOCK  MODE  FILE  TRANSFER 
ALL  ARCHITECTDRE  LAYERS 


RAT 

NONE 

INFORMATION  ABODT  THE  ATTRIBOTES  OF  THE  INDIVIDDAL  RECORDS 
SDCH  AS  TYPE  OF  CARRAGE  CONTROL,  LINE  FEED,  ETC. 

ALL  ARCHITECTURE  LAYERS 


received  jm:  CES  S_COMPLETE_ERRORS 
NONE 


RECEIVED_ACCESS_COMPLETE_ERRORS  = 

M RECEIVED _UNSDPPORT_ACC/COMP 
I  RECE IVED_FO  RMAT_AC  C/ COMP 
I  RECE IVED_SYNC_^C C/COMP 
I  RECEIVED_DNSUPPORT_MISC 
I  RECEIVED_FORMAT_MISC 
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■  V 


NOTES : 


DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 
NOTES : 

DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 

DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 

DATA-FLOW .NAME: 
ALIASES: 


I  RECE IVED.SYNC.UNKNOWN 


EXECUTE  STARTUP  PACKETS  LAYER 
EXECUTE  ACC/ACK  PACKETS  LAYER 


RECEIVED^ AC CE  S  S_COMPLETE_PACKET 
ACCES  S_COMPLETE_PACKET 
VALID.RECEIVED.ACCES  S.COMPLETE.PACKET 
RECEIVED_AC COMP( COMMAND ) 

RECEIVED_AC COMP ( PURGE ) 

RECEIVED JCCOMP(RESPONSE) 

RECEIVED_AC COMP ( EOS ) 

SEE  ALIASES 

EXECUTE  ACC/ACK  PACKETS  LAYER 

EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 


RECEIVED_ACCES S_PACKET 
ACCES S_PACKET 

VAL ID_RECE I VED_AC  CES  S_PACKET 
AC  CES  S ( ERASE )  JPACKET 
AC  CES  S ( RENAME ) .PACKET 
ACCESS(ECF)_PACKET 
ACCES S(SCF)  JPACKET 

SEE  ALIASES 

EXECUTE  STARTUP  PACKETS  LAYER 


RECE IVED  JC  COMP ( COMMAND ) 

ACCES  S.COMPLETE JACKET 
RECEIVED _AC CE  S  S.COMPLETE.PACKET 
VALID.RECE  IVEDJC  CE  S  S.COMPLETE.PACKET 
RECEIVED  JC  COMP  (PURGE ) 

RECEIVED _ACCOMP( RESPONSE) 

RECEIVED JC  COMP(  EOS ) 

SEE  ALIASES 

EXECUTE  ACC/ACK  PACKETS  LAYER 


RECEIVED _AC COMP ( EOS ) 

ACCES  S.COMPLETE JACKET 
RECEIVED JC  CE  S  S.COMPL  ETE JACKET 
VALID  JECEIVEDJC  CES  S.COMPLETE  JACKET 
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COMPOSITION: 

NOTES: 

DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 

DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 
NOTES : 

DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES : 


RECE I VED_AC COMP ( COMMAND ) 

RECE IVED  JVC COMP ( PURGE ) 

RECE I VED_AC  COMP ( RESPONSE ) 

SEE  ALIASES 

EXECUTE  ACC/ACK  PACKETS  LAYER 


RECEIVED  JVCCOMP ( PURGE ) 

ACCES  S_COMPLETE_PACKET 
RECE IVED_AC CE  S  S_COMPLETE_PACKET 
VALID_RECEIVED_AC CE  S  S_COMPLETE_PACKET 
RECEIVED  JVCCOMP(COMMAND) 

RECE IVED_ACCOMP( RESPONSE) 

RECEIVED  JVC COMP( EOS) 

SEE  ALIASES 

EXECUTE  ACC/ACK  PACKETS  LAYER 


RECEIVED  _AC COMP ( RESPONSE) 

ACCES  S_COMPLETE_PACKET 
RECE IVED _ACCESS_COMPLETE_PACKET 
VAL ID_RECE IVED  JVC  CE  S  S_COMPLETE_PACKET 
RECEIVED  JVC  COMP ( COMMAND ) 

RECE IVED  JVC  COMP (PURGE ) 

RECE  IVED  JVC  COMP  (  EOS  ) 

SEE  ALIASES 

EXECUTE  ACC/ACK  PACKETS  LAYER 


RECEIVED  JVC  CJERRORS 
NONE 

RECEIVED  JVC C_ERRORS  =  I  RECEIVEDJJNSUPPORTJVCCESS 

I  RECE IVED_UNSUPPORT_MISC 
I  RECE IVED_FORMAT JVC CESS 
I  RECEIVED_FORMAT_MISC 
I  RECE I VED_SYNC_AC CESS 
I  RECE IVED_SYNC_UNKNOWN 

EXECUTE  STARTUP  PACKETS  LAYER 


DATA  FLOW  NAME 
ALIASES: 


RECEIVED  JVCK_ERR0RS 
NONE 


COMPOSITION 


NOTES: 


DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


RECEIVED_ACK  ERRORS  =  !  RECEIVED_UNSUPPORT_MISC 

I  RECEIVED_UNSUPPOET_ACK 
|  RECEIVED_FORMAT_ACK 
I  RECEIVED_FORMATJ<ISC 
|  RECEIVED_SYNC_ACK 
I  RECE IVED_SYNC_UNKNOWN 

EXECUTE  STARTUP  PACKETS  LAYER 


RECEIVED  JW:KNOWLEDGE_PACKET 

ACKNOWLEDGE_PACRET 

VALID_RECE I VED_ACKNOWLEDGE_PACKET 

SEE  ALIASES 

EXECUTE  STARTUP  PACKETS  LAYER 


RECEIVED_ADD_GET_PACKET 

ADD_GET_PACKET 

SEE  ALIASES 

EXECUTE  CONTROL  PACKETS  LAYER 
EXECUTE  CONTINUE  PACKETS  LAYER 


RECEIVED  JU)D_PUT_PACKET 
ADD_PUT_PACKET 

SEE  ALIASES 

EXECUTE  CONTROL  PACKETS  LAYER 
EXECUTE  CONTINUE  PACKETS  LAYER 


RECEIVED_ATTRIB/AC C_PACKET 
ATTRI B/ AC  C_PACKE  T 

SEE  ALIASES 

EXECUTE  STARTUP  PACKETS  LAYER 


RECEIVED  JHTRIB/ACK_PACKET 
ATTRI B/ACK_PACKET 

SEE  ALIASES 
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NOTES 


EXECUTE  STARTUP  PACKETS  LAYER 


DATA  FLOW  KANE: 
ALIASES : 
COMPOSITION: 


NOTES: 


DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 


DATA  FLOW  NAME: 
ALIASES : 
COMPOSITION: 

NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  FLOW  NAME: 


RECEIVED  _ATTRI B_ERR0RS 
NONE 

RECE IVED_ATTRI B_ERRORS  =  T~ RECEIVED_UNSUPPORT_ATTRIB 

!  RECEIVED_FORMAT_ATTRIB 
I  RECE IVED_SYNC_ATTRI B 
I  RECE IVED_UNSUPPORT_MISC 
I  RECEIVED_FORMAT_MISC 
I  RECEIVED_SYNC_UNKNOWN 

EXECUTE  STARTUP  PACKETS  LAYER 


RECEIVED_ATTRIBUTES_PACKET 

ATTRIBUTES_PACKET 

VALID_RECEIVED_AII2IBUTES_PACKET 

SEE  ALIASES 

EXECUTE  STARTUP  PACKETS  LAYER 


RECEIVED_DATAW.FILE 

DATA_PACKET 

SEE  ALIASES 

EXECUTE  CONTINUE  PACKETS  LAYER 

EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 


RECEIVED_CONFIG_ERRORS 

NONE 


RECE I VED_C0NFI  G_E  RRORS  = 


RECEIVED_UNSUPPORT_CONFIG 

RECEIVED_FORMAT_CONFIG 

RECE  IVED_SYNC_CONFIG 

RECEIVED_UNSUPPORT_MISC 

RECEIVED_FORMAT_MISC 

RECEIVED_SYNC_UNKNOV7N 


EXECUTE  STARTUP  PACKETS  LAYER 


RECEIYED_CONFIGURATION_PACKET 
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ALIASES: 

COMPOSITION: 

NOTES: 

DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


DATA  FLOW  NAME: 
ALIASES : 

COMPOSITION: 
NOTES : 

DATA  FLOW  NAME: 
ALIASES : 

COMPOSITION: 

NOTES: 

DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


DATA  FLOW  NAME: 


CONFIGURATION_PACKET 

VAL ID_RECE I VED_CONFIGURATION_PACKET 

SEE  ALIASES 

EXECUTE  STARTUP  PACKETS  LAYER 


RECE IVED_CONNECT_PACKET 
CONNECT_PACKET 

SEE  ALIASES 

EXECUTE  CONTROL  PACKETS  LAYER 


RECEIVED_CONTINUE^ABORT_PACKET 

CONTINUE_ONLY_PACKET 

CONTINUE_ABORT_PACKET 

CONT INUE_SK I P_PACKE  T 

RECE IVED_CONT INUE_ONLY_PACKE T 

RECEIVED_CONTINUE„SKIP_PACKET 

SEE  ALIASES 

EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 
EXECUTE  ACC/ACK  PACKETS  LAYER 


RECEIVED_CONTINUE_ONLY_PACKET 
CONT INUE_ONLY_PACKET 
CONT INUE_SKIP_PACKET 
CONTINUE_ABORT_PACKET 
RECEIVED_CONTINUE— SKIP_PACKET 
RECE I VED_CONT INUE  _>BORT_PACKET 

SEE  ALIASES 

EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 
EXECUTE  CONTINUE  PACKETS  LAYER 


RECEIVED_CONT INUE_PACKE  TS 
CONTINUE_INTERRUPT_PACKET 

SEE  ALIASES 

EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 


RECE I VED_CONT INUE_SKI P_PACKET 
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ALIASES 


COMPOSITIONS 

NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES : 


DATA  FLOW  NAME: 
ALIASES : 
COMPOSITION: 


NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


C  ONT INUE_ONLY_PACKE  T 

CONT INUE_ABORT_PACKET 

CONT INUE_SKIP_PACKET 

RECE I  VED_CONT  INUE_JABORT_PACKET 

RECZIVED_CONTINUE_ONLY_PACKET 

SEE  ALIASES 

EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 
EXECUTE  CONTINUE  PACKETS  LAYER 


RECE I VED_C0NT INUE_STATUS 
NONE 

RECEIVED_CONTINUE_STATUS  = 

T  RECE IVED_OPERATION_IN_PROGRES  S 
|  RECEIVED_SUCCESSFUL_OPERATION 
|  RECE I VED_SYNC_PATA 
|  RECEIVED_FORMAT_DATA 
|  RECEIVED_UNSUPPORT_DATA 
I  RECE IVED_FILE_ERRORS 

EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 


RECE IVED_CONTRQL_ERRORS 
NONE 

RECE I VED_CONTROL_ERRORS  =  |  RECEIVED_UNSUPPORT_CONTRQL 

|  RECE  IVED_SYNC_CONTROL 
|  RECE IVED_FORMAT_CONTROL 
|  RECEIVED_UNSUPPORT_MISC 
I  RECE IVED_FORMAT_MISC 
I  RECEIVED_SYNC_UNKNOWN 

EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 
EXECUTE  CONTROL  PACKETS  LAYER 
CODE  ARCHITECTURE  PACKETS  LAYER 


RECEIVED_CONTROL_PACKET 

CONTROL_PACKET 

SEE  ALIASES 

EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 
EXECUTE  CONTROL  PACKETS  LAYER 


RECEIVED_CONTROL_STATUS 
NOME 

RECEIVED_CONTROL_ STATUS  =  M RECEIVED_UNSUPPORT_CONTROL~ 

I  RECEIVED_FORMAT_CONTROL  I 
I  RECEIVED_SYNC_CONTROL  I 

NOTES:  EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 


DATA  ELEMENT  NAME:  RECEIVED_EOF 

ALIASES:  EOF 

VALUES  AND  MEANINGS: 

RECEIVED  END-OF-FILE  SUCCESSFULLY. 
NOTES:  DECODE  STATUS  PACKETS  LAYER 

EXECUTE  ACC/ACK  PACKETS  LAYER 


DATA  ELEMENT  NAME:  RECEIVED_FILE_ERRORS 

ALIASES:  FILE_ERRORS 

VALUES  AND  MEANINGS: 

1.  ERRORS  THAT  OCCUR  BEFORE  A  FILE  IS  SUCCESSFULLY 
OPENED. 

2.  ERRORS  THAT  OCCUR  AFTER  OPENING  A  FILE  AND  BEFORE 
CLOSING  THAT  FILE. 

3.  ERRORS  ASSOCIATED  WITH  TERMINATING  ACCESS  TO  A  FILE. 

NOTES:  DECODE  STATUS  PACKETS  LAYER 

EXECUTE  CONTINUE  PACKETS  LAYER 


DATA  FLOW  NAME:  RECEIVED_FILE_STATUS 

ALIASES :  NONE 

COMPOSITION:  _  _ 

RECEIVED_FILE_STATUS  =  I  RECE IVED_FILE_ERRORS  | 

I  RECEIVED_TIMEOUT  I 

NOTES:  DECODE  STATUS  PACKETS  LAYER 


DATA  ELEMENT  NAME:  RECEIVED_FORMAT^ACC/COMP 

ALIASES:  RECEIVED_FORMAT_MISC 

VALUES  AND  MEANINGS: 

SEE  ALIASES 

NOTES:  DECODE  STATUS  PACKETS  LAYER 

EXECUTE  ACC/ACK  PACKETS  LAYER  k 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 
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DATA  ELEMENT  NAME:  RECEIVED_FORMAT_-AC CESS 

ALIASES :  RECEIVED_FORMAT_MISC 

VALUES  AND  MEANINGS: 

SEE  ALIASES 

NOTES:  DECODE  STATUS  PACKETS  LAYER 

EXECUTE  STARTUP  PACKETS  LAYER 


RECEIVED_FORMAT^ACK 

RECEIVED_FORMAT__MISC 

SEE  ALIASES 

DECODE  STATUS  PACKETS  LAYER 
EXECUTE  ACC/ACK  PACKETS  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME:  RECEIVED_FORMAT^ATTRIB 

ALIASES :  RECEIVED_FORMAT_MISC 

VALUES  AND  MEANINGS: 

SEE  ALIASES 

NOTES:  DECODE  STATUS  PACKETS  LAYER 

EXECUTE  STARTUP  PACKETS  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


RECEIVED_FORMAT_CONFIG 

RECEIVED_FORMAT_MISC 

SEE  ALIASES 

DECODE  STATUS  PACKETS  LAYER 
EXECUTE  STARTUP  PACKETS  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES ! 


RECE IVED_FORMAT_CONT INUE 
RECEIVED_FORMAT_MISC 

SEE  ALIASES 

DECODE  STATUS  PACKETS  LAYER 
EXECUTE  CONTINUE  PACKETS  LAYER 


DATA  ELEMENT  NAME:  R£CEIVED_FORMAT_CONTROL 
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ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 


VALUES  AND  MEANINGS: 


NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


1 


RECEIVED_FORMAT_MISC 


SEE  ALIASES 

DECODE  STATUS  PACKETS  LAYER 
GENERATE  CONTROL  PACKETS  LAYER 


RECE I VED_FORMAT_DATA 
RECEIVED_FORMAT_MISC 

SEE  ALIASES 

DECODE  STATUS  PACKETS  LAYER 
EXECUTE  CONTINUE  PACKETS  LAYER 


RECEIVED_FORMAT_MISC 
RECEIVED-FORMAT_CONFIG 
RECEIVED-FORMAT^ATTRIB 
RECE I VED - FORMAX^AC  CESS 
RECE IVED_FORMAT_CONT INUE 
RECE IVED_FORMAT_CONTROL 
RECE I VED_FO  RMAT_ACK 
RECEIVED_FORMAT_ACC/ACK 
RECE I VED_FO RMAT_DATA 
RECEIVED_FORMAT_STATUS2 

1.  ERROR  IN  PARSING  THE  PARTICULAR  PACKET. 

2.  FIELD  OF  THE  PARTICULAR  PACKET  IS  INVALID  (e.g.,  BITS 
THAT  ARE  MEANT  TO  BE  MUTUALLY  EXCLUSIVE  ARE  SET,  AN 
UNDEFINED  BIT  IS  SET,  A  FIELD  VALUE  IS  OUT  OF  RANGE 
OR  AN  ILLEGAL  STRING  IS  IN  A  FIELD) . 

DECODE  STATUS  PACKETS  LAYER 
CODE  ARCHITECTURE  PACKETS  LAYER 


RECEIVED_FORMAT_STATUS 

NONE 

RECEIVED_FORMAT_STATUS  =  1  RECEIVED_FORMAT_MISC 

I  RECEIVED_FORMAT_ACC/ COMP 
|  RECEIVED_FORMAT_CONFIG 
I  KECEIVED_FORMAT _ATTRIB 
|  RECEIVED_FORMAT ^ACCESS 
I  RECE lVED_FORMAT_CONT INUE 
I  RECE I VED_FO  RMAT_CONTRQL 
I  RECEIVED_FORMAT_ACK 
j  RECE IVED_FORMAT_DATA 
I  RECE I VED_FO  RMAT_STATU  S  2 
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NOTES 


DECODE  STATUS  PACKETS  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


t 

* 

» 


REC  E I VED_FO  RMAT_ST ATU  S  2 
RECEIVED_FORMAT_MISC 

SEE  ALIASES 

DECODE  STATUS  PACKETS  LAYER 
CODE  ARCHITECTURE  PACKETS  LAYER 


RECEIVED_GET_PACKET 

GET_PACKET 

SEE  ALIASES 

EXECUTE  CONTROL  PACKETS  LAYER 

EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 


RECEIVED_KEY_GET_PACKET 

KEY_GET_PACKET 

SEE  ALIASES 

EXECUTE  CONTROL  PACKETS  LAYER 
EXECUTE  CONTINUE  PACKETS  LAYER 


RECEIVED  J(CEY_PUT_PACKET 
KEY_PUT_PACKET 

SEE  ALIASES 

EXECUTE  CONTROL  PACKETS  LAYER 
EXECUTE  CONTINUE  PACKETS  LAYER 


RECEIVED_OPERATION_IN_PROGRESS 
RECEIVED_PENDING_STATUS 
OPERATION_IN_PROGRES S 

SEE  ALIASES 

DECODE  STATUS  PACKETS  LAYER 
EXECUTE  CONTINUE  PACKETS  LAYER 


219 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES : 


DATA  FLOW  NAME: 
ALIASES : 
COMPOSITION: 


RECEIVED_PENDING_STATUS 

RECE IVED_OPE  RAT ION_IN_PROGRES  S 

OPERATION_IN_PROGRESS 

STATUS  MESSAGE  INDICATING  THAT  PAST  SENT  DATA  PACKETS  ARE 
BEING  STORED /APPENDED,  ETC.  AND  THAT  ALL  IS  WELL. 

DECODE  STATUS  PACKETS  LAYER 


RECEIVED_PUT_PACRET 

PUT_PACKET 

SEE  ALIASES 

EXECUTE  CONTROL  PACKETS  LAYER 

EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 


RECEIVED_SEQ_GET_PACKET 

SEQ_GET_PACKET 

SEE  ALIASES 

EXECUTE  CONTROL  PACKETS  LAYER 
EXECUTE  CONTINUE  PACKETS  LAYER 


RECEIVED_SEQ_PUT_PACKET 

SEP_PUT_PACKET 

SEE  ALIASES 

EXECUTE  CONTROL  PACKETS  LAYER 
EXECUTE  CONTINUE  PACKETS  LAYER 


RECEIVED  _STARTUP_P ACRE TS 
NONE 

RECEIVED_STARTUP_PACKETS  = 


RECEIVED_CONFIGURATION_PACKET 
RECEIVED^ ACKNOWLEDGE_PACKET 
RECEIVED_ATTRIB/ ACK_PACKET 
RECEIVED_ATTRIBUTES_PACKET 
RECE IVED_ATTRIB/ AC  C_PACKET 
RECE IVED_AC CE  S  S_PACKET 


NOTES 


EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 
CODE  ARCHITECTURE  PACKETS  LAYER 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES : 


RECE I VED_ST ARTD  P_STATU  S 
NONE 


RECEIVED_STARTUP_STATUS  = 


RECE  I  VED_UNSUPPORT_JAC  C/COMP 
RECEIVED_SYNC_CONFIG 
RECEIVED_FORMAT_CONFIG 
RECEIVED_DNSUPPORT_CONFIG 
RECE I VED_FO  RMATJttTRI B 
RECE  IVED_FORMAT_JAC  CESS 
RECE I VED_DNSDP  PC  RT_ATTRI B 
RECE IVED_SYNC_ATTRI B 
RECE IVED_DNSDPPORT_AC CE S S 
RECE IVED_SYNC_AC  CESS 
RECEIVED_FORMAT_ACC/COMP 
RECE IVED_SYNC_AC C/COMP 
RECE I VED_UNSUP  PO  RT_ACK 
RECE I VED_SYNC_ACK 
RECE I VED_FO  RMAT_ACK 
RECEIVED_EOF 
RECEIVED_TIMEOUT 


EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 


RECE I VED_STATU  S_ERROR 
NONE 


RECE IVED_STATU S_ERROR  =  I  RECEIVED_UNSUPPORT_STATUS  I 

i  RECE IVED_FORMAT_STATU  S  I 
I  RECE IVED_SYNC_STATU  S  I 


DECODE  STATUS  PACKETS  LAYER 

CODE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 


RECE IVED_STATU  S_PACKET 
VALID_RECEIVED_STATUS_PACKET 


RECE I VED_ST ATU  S_PACKE  T  = 


RECE I VED_SUC  CE  S  SFUL_STATU  S 
RECE I VED_U NSUP PO  RT_ST ATU  S 
RECE IVED_PENDING_STATU  S 
RECE IVED_FO RMAT_ST ATU S 
RECEIVED_SYNC_STATUS 
RECE IVED_FILE_STATUS 


EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 
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DECODE  STATUS  PACKETS  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  FLOW  NAME: 
ALIASES : 
COMPOSITION: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


RECE IVED_SUC CES SFUL_OPERAT ION 
SUCCESSFUL_OPERATION 

RETURNS  INFORMATION  THAT  INDICATES  SUCCESS.  USED  WHEN 
PERFORMING  RECORD-STORE  ACTIONS. 

DECODE  STATUS  PACKETS  LAYER 
EXECUTE  CONTINUE  PACKETS  LAYER 


RECEIVED_SUCCESSFUL_STATUS 

NONE 

RECE I VED_SUC  CE  S  SFUL_ST ATU  S  = 

1” RECEIVED_SUCCESSFUL_OPERATION  | 
I  RECEIVED_EOF  I 


DECODE  STATUS  PACKETS  LAYER 


RECEIVED_SYNC_ACC/COMP 

RECEIVED_SYNC_UNKNOWN 

SEE  ALIASES 

DECODE  STATUS  PACKETS  LAYER 
EXECUTE  ACC/ACK  PACKETS  LAYER 


RECE I VED_SYN C_AC  CESS 
RECEIVED_SYNC_UNKNOWN 

SEE  ALIASES 

DECODE  STATUS  PACKETS  LAYER 
EXECUTE  ACC/ACK  PACKETS  LAYER 


RECEIVED_SYNC^ACK 
RECE IVED_SYNC_UNKN OWN 

SEE  ALIASES 

DECODE  STATUS  PACKETS  LAYER 
EXECUTE  ACC/ACK  PACKETS  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 
NOTES : 


DATA  FLOW  NAME: 
ALIASES: 
COMPOSITION : 


RECEIVED_SYNC _ATTRIB 
RECE IVED_SYNC_UNKN OWN 

SEE  ALIASES 

DECODE  STATUS  PACKETS  LAYER 
EXECDTE  STARTDP  PACKETS  LAYER 


RECEIVED_SYNC_CONFIG 

RECEIVED_SYNC_DNKNOWN 

SEE  ALIASES 

DECODE  STATUS  PACKETS  LAYER 
EXECDTE  STARTUP  PACKETS  LAYER 


RECEIVED_SYNC_CONT INUE 
RECEIVED_SYNC_UNKNOWN 

SEE  ALIASES 

DECODE  STATUS  PACKETS  LAYER 
EXECUTE  CONTINUE  PACKETS  LAYER 


RECEIVED_SYNC_CONTROL 
RECE I VED_SYNC_UNKNOWN 

SEE  ALIASES 

DECODE  STATUS  PACKETS  LAYER 
GENERATE  CONTROL  PACKETS  LAYER 


RECE IVED_SYNC_DATA 
RECEIVED_SYNC_UNKNOWN 

SEE  ALIASES 

DECODE  STATUS  PACKETS  LAYER 
EXECUTE  CONTINUE  PACKETS  LAYER 


RECE I VED_SYNC_STATU  S 
NONE 

RECE I VED_SYNC_STATU S  =  M RECEIVED_SYNC_CONFIG 
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NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 


VALUES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


I  RECE IVED_SYNC_ATTRI B 
I  RECEIVED_SYNC_ACCES  S 
I  RECE I VED_SYNC_CONTROL 
I  RECE I VED_S YNC_CONT INUE 
I  RECE IVED_SYNC_ACK 
I  RECE I VED_SYNC_AC C/COMP 
I  RECE IVED_SYNC_DATA 
I  RECE I V ED_SYN C_ST ATU  S  2 
I  RECETVED_SYNC_UNKNOWN 

DECODE  STATUS  PACKETS  LAYER 


RECE IVED_SYNC_STATU  S  2 
RECE I VED_SYNC_UNKNOWN 

SEE  ALIASES 

DECODE  STATUS  PACKETS  LAYER 
CODE  ARCHITECTURE  PACKETS  LAYER 


RECE IVED_SYNC_UNKNOWN 
RECEIVED_SYNC_CONFIG 
RECE IVED.SYNC^ATTRI B 
RECEIVED_SYNC_ACCESS 
RECE IVED_SYNC_CONTR  QL 
RECEIVED_SYNC_CONTINUE 
RECEIVED_SYNC_ACK 
RECEIVED_SYNC_AC C/COMP 
RECEIVED_SYNC_DATA 
RECE I VED_S  YN C_ST ATU S  2 

THE  PARTICULAR  PACKET  WAS  RECEIVED  OUT  OF  SYNCHRONIZATION. 
DECODE  STATUS  PACKETS  LAYER 
CODE  ARCHITECTURE  PACKETS  LAYER 


RECEIVED_TIMEOUT 

TIMEOUT 

A  STATUS  PACKET  INDICATING  THAT  THE  ACCESSED  SYSTEM  (NODE) 
RECEIVED  A  CONFIGURATION,  ACCESS  ATTRIBUTES,  OR  ACCESS. 
COMPLETE.PACKET  AND  HAS  NOT  RECEIVED  THE  APPROPRIATE 
PACKETS  TO  RESET  THE  TIMER.  OR  THE  ACCESSED  SYSTEM  HAS 
RECEIVED  A  ACCESS.COMPLETE(RESPONSE)  BUT  AFTER  A  SUITABLE 
AMOUNT  OF  TIME  NO  OTHER  COMMAND  IS  RECEIVED.  WHEN  A 
TIMEOUT  IS  SENT  THE  LOGICAL  LINK  IS  ALSO  TERMINATED. 

DECODE  STATUS  PACKETS  LAYER 
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EXECUTE  STARTUP  PACKETS  LAYER 
EXECUTE  ACC/ACK  PACKETS  LAYER 


DATA  ELEMENT  NAME:  RECEIVEDJJNSUPPORTJWC/COMP 
ALIASES:  RECEIVED_UNSUPPORT_MISC 

VALUES  AND  MEANINGS: 

SEE  ALIASES 

NOTES:  DECODE  STATUS  PACKETS  LAYER 

EXECUTE  ACC/ACK  PACKETS  LAYER 


DATA  ELEMENT  NAME:  RECEIVED_UNSUPPORT_JACCESS 
ALIASES:  RECEIVEDluNSUPPORT_MISC 

VALUES  AND  MEANINGS: 

SEE  ALIASES 

NOTES:  DECODE  STATUS  PACKETS  LAYER 

EXECUTE  ACC/ACK  PACKETS  LAYER 


DATA  ELEMENT  NAME:  RECEIVED_UNSUPPORT_ACK 
ALIASES:  RECEIVED_UNSUPPORT_MISC 

VALUES  AND  MEANINGS: 

SEE  ALIASES 

NOTES:  DECODE  STATUS  PACKETS  LAYER 

EXECUTE  ACC/ACK  PACKETS  LAYER 


DATA  ELEMENT  NAME:  RECEIVED_UNSUPPORT_ATTRIB 
ALIASES :  RECEIVED_UNSUPPORT_MISC 

VALUES  AND  MEANINGS: 

SEE  ALIASES 

NOTES:  DECODE  STATUS  PACKETS  LAYER 

EXECUTE  STARTUP  PACKETS  LAYER 


DATA  ELEMENT  NAME:  RECEIVED_UNSUPPORT_CONFIG 
ALIASES:  REC E IVED_UN SUP PO RT  MISC 

VALUES  AND  MEANINGS: 

SEE  ALIASES 

NOTES:  DECODE  STATUS  PACKETS  LAYER 

EXECUTE  STARTUP  PACKETS  LAYER 


DATA  ELEMENT  NAME:  RECEIVED_UNSUPPORT_CONTINUE 
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ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 


VALUES  AND  MEANINGS: 


NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


RECE I VED_UNSUPPORT_MISC 
SEE  ALIASES 

DECODE  STATUS  PACKETS  LAYER 
EXECUTE  CONTINUE  PACKETS  LAYER 


RECEIVED_UNSUPPORT_CONTROL 

RECEIVED_UNSUPPORT_MISC 

SEE  ALIASES 

DECODE  STATUS  PACKETS  LAYER 
GENERATE  CONTROL  PACKETS  LAYER 


RECEIVED_UNSUPPORT_DATA 

RECEIVED_L'NSUPPORT_MISC 

SEE  ALIASES 

DECODE  STATUS  PACKETS  LAYER 
EXECUTE  CONTINUE  PACKETS  LAYER 


RECEIVED_UNSUPPORT_MISC 
RECEIVED_UNSUPPORT_CONFIG 
RECE I VED_UN SUP PO  RT_ATTRI B 
RECEIVED_UNSUPPORT_ACCESS 
RECE I VED_UNSUP  PORT_CONT INUE 
RECE I VED_JN SUP  PO  RT_CO NTR OL 
RECEIVED_UNSUPPORT_-ACK 
RECEIVED_UNSUPPORT_ACC/COMP 
RECE  IVED_UNSUP  PO  RT__DATA 
RECE I VED_UNSUP  PO  RT^STATU  S  2 

THIS  IS  USED  WHEN  AN  UNSUPPORTED  BIT/FIELD  OR  A  FIELD/ 
VALUE,  FOR  A  PARTICULAR  PACKET  TYPE,  IS  ENCOUNTERED  WHICH 
A  PARTICULAR  IMPLEMENTATION  DOES  NOT  SUPPORT. 

DECODE  STATUS  PACKETS  LAYER 
CODE  ARCHITECTURE  PACKETS  LAYER 


RECEIVED_UNSUPPORT_STATUS 

NONE 

RECEIVED_UNSUPPORT_STATUS  =  T RECEIVED_UNSUPPORT_CONTINUE  I 

I  RECE IVED_UNSUPPORT_MISC  I 

I  RECEIVED_UNSUPPORT_CONFIG  I 
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NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


RECE I VED_UNSUPPORT^ATTRIB 
RECE IVED_UNSUPPORT_ACCESS 
RECEIVED_UNSUPPORT_CONTRQL 
RECEIVED_UNSUPPORT_ACK 
RECE IVED_UNSUPPORT_ACC/ COMP 
RECE I VED_UNSUPPO  RT_DATA 
RECE IVED_UNSUPPORT_STATUS2 


DECODE  STATUS  PACKETS  LAYER 


RECEIVED_UNSUPPORT_STATUS2 

RECEIVED_UNSUPPORT_MISC 

SEE  ALIASES 

DECODE  STATUS  PACKETS  LAYER 
CODE  ARCHITECTURE  PACKETS  LAYER 


RECNUM 

NONE 

THIS  FIELD  IS  USED  TO  SEND  THE  RECORD  NUMBER  WHEN  ACCESSING 
RELATIVE  FILES.  FOR  RANDOM  STORE.  THIS  FIELD  WILL  CONTAIN 
THE  RECORD  NUMBER.  WHEN  IN  THE  BLOCK  MODE.  THIS  FIELD 
WILL  CONTAIN  THE  VIRTUAL  BLOCK  NUMBER. 

ALL  ARCHITECTURE  LAYERS 


RESEND_INFO 

NONE 

A  FLAG  TO  INDICATE  THAT  THE  BAD  RECORD  SHOULD  BE  RESENT 
AND  THEN  CONTINUE  ON  UNTIL  EOF. 

EXECUTE  CONTINUE  PACKETS  LAYER 


RFA 

NONE 

USED  TO  RETURN  THE  RECORD  FILE  ADDRESS  OF  THE  RECORD  TO 
WHICH  THIS  STATUS  PACKET  APPLIES. 

ALL  ARCHITECTURE  LAYERS 


DATA  ELEMENT  NAME 


RFM 


ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


NONE 

FORMAT  OF  THE  RECORDS  BEING  TRANSFERRED. 
ALL  ARCHITECTURE  LAYERS 


ROP 

NONE 

OPTIONAL  RECORD  PROCESSING  FEATURES  SUCH  AS  POSITION  OF 
EOF. 

ALL  ARCHITECTURE  LAYERS 


RUNSYS 

NONE 

NAME  OF  THE  RUN-TIME  SYSTEM  ENVIROMENT  REQUIRED  TO  EXECUTE 
THE  CODE  CONTAINED  IN  THE  FILE.  THIS  FIELD  IS  USEFUL  TO 
TO  OPERATING  SYSTEMS  THAT  CAN  EMULATE  OTHER  OPERATING 
SYSTEM  ENVIROMENTS. 

ALL  ARCHITECTURE  LAYERS 


SECONDARY_INCOMING_DIALOGUE_COMMANDS 

PRIMARY_INCOMING_DIALOGUE_COMMANDS 

SEE  ALIASES 
OVERVIEW  LAYER 


SECONDARY_OUTGOING_DIALOGUE_COMMANDS 

PRIMARY_OUTGOING_DIALOGUE_COMMANDS 

SEE  ALIASES 
OVERVIEW  LAYER 


SECONDARY_START_FILE_CONFIGURATION 

PRIMARY_START_FILE_CONFIGURATION 

SEE  ALIASES 
OVERVIEW  LAYER 
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DATA  ELEMENT  NAME:  SECOND_ATTRIB_FLAG 
ALIASES:  NONE 

VALDES  AND  MEANINGS: 

A  FLAG  USED  TO  INDICATE  THAT  THIS  NODE  HAS  NOT  PREVIOUSLY 
ISSUED  AN  ATTRIBUTES  PACKET  BUT  HAS  RECEIVED  ONE. 

NOTES:  EXECUTE  STARTUP  PACKET  LAYER 


DATA  ELEMENT  NAME:  SECOND_CONFIG_FLAG 
ALIASES:  NONE 

VALUES  AND  MEANINGS: 

A  FLAG  USED  TO  INDICATE  THAT  THIS  NODE  HAS  NOT  PREVIOUSLY 
ISSUED  A  CONFIGURATION_PACRET  BUT  HAS  RECEIVED  ONE. 

NOTES:  EXECUTE  STARTUP  PACKET  LAYER 


DATA  FLOW  NAME:  SEQ_GET_PACKET 

ALIASES:  RECEIVED_SEQ_GET_PACKET 

COMPOSITION: 

SEQ_GET_PACKET  =  OPERATOR  +  TYPE=4  +  CTLFUNC  +  CTLMENU  + 
RAC  +  ROP 

NOTES:  GENERATE  CONTROL  PACKETS  LAYER 


DATA  FLOW  NAME:  SEQ_PUT_PACKET 

ALIASES:  RECEIVED_SEQ_PUT_PACRET 

COMPOSITION: 

S  EQ_PUT_P ACRE  T  =  OPERATOR  +  TYPE=4  +  CTLFUNC  +  CTLMENU  + 
RAC  +  ROP 

NOTES:  GENERATE  CONTROL  PACKETS  LAYER 


DATA  FLOW  NAME:  SETUPJSRRORS 

ALIASES:  NONE 

COMPOSITION:  _  _ 

SETUP_ERRORS  =  I  RECEIVED^ AC CE S  S_COMPLETE_ERRORS  I 

I  RECEIVED_CONFIG_ERRORS  I 

I  RECE IVED_ACK_ERRORS  I 

I  RECE IVED_ATTRI B_ERRORS  I 

I  RECEIVED_^CC_ERRORS  I 

NOTES:  EXECUTE  STARTUP  PACKETS  LAYER 

EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 
CODE  ARCHITECTURE  PACKETS  LAYER 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS 
NOTES : 


SETUP_PACKETS 

NONE 

SETUP_PACKETS  =  I  ACCESS_COMPLETE_PACKET  | 

I  ATTRIB/ACK_PACKET  I 

I  ACKNOWLEDGE_PACKET  | 

I  AC  CE  S S_PACKE  T  I 

I  ATTRIB/ACC_PACKET  I 

I  ACC/ER_PACKET  I 

I  ACC/ECF / SCF_PACKET  I 

I  ATTRIBUTES_PACKET  I 

EXECUTE  STARTUP  PACKET  LAYER 

EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 

CODE  ARCHITECTURE  PACKETS  LAYER 


SHR 

NONE 

OPERATIONS  SHARED  WITH  OTHER  USERS. 
ALL  ARCHITECTURE  LAYERS 


SKIP_INFO/ CONTINUE 
SKIP_REC/CONTINUE 

SEE  ALIASES 

EXECUTE  CONTINUE  PACKETS  LAYER 


SKIP_REC /CONTINUE 
SKIP_INFO/ CONTINUE 

A  FLAG  USED  TO  INDICATE  THAT  THE  BAD  RECORD  SHOULD  BE 
SKIPPED  OVER  AND  THE  REMAINING  RECORDS  PROCESSED. 
EXECUTE  CONTINUE  PACKETS  LAYER 


START.^ ACC/COMP 
START_ER/ECF_COMP 

SEE  ALIASES 

EXECUTE  ACC/ACK  PACKETS  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


START^AC  C_ECF 
NONE 

A  FLAG  USED  TO  START  GENERATION  OF  AN  ACCESS(ECF)  OR 
ACCESS(SCF)  PACKETS. 

EXECUTE  STARTUP  PACKETS  LAYER 


START _AC C_ER 
NONE 

A  FLAG  USED, TO  INDICATE  THE  GENERATION  OF  AN  ACCESS(ERASE) 
PACKET,  OR  ACCESS (RENAME)  PACKET. 

EXECUTE  STARTUP  PACKETS  LAYER 


START_ ACCESS 
NONE 

A  FLAG  USED  TO  INDICATE  THAT  THE  LAST  ATTRIBUTES  PACKET 
HAS  BEEN  RECEIVED  AND  A  ACCESS  PACKET  CAN  NOW  BE  GENERATED 
AND  OUTPUTTED. 

EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 
EXECUTE  STARTUP  PACKETS  LAYER 
EXECUTE  ACC/ACK  PACKETS  LAYER 


START  JVTTRIB/ACC 
NONE 

A  FLAG  USED  TO  INDICATE  THE  GENERATION  OF  A  ATTRIBUTES/ 
ACCESS  PACKET  (ATTRIB/ACC_PACKET) . 

EXECUTE  STARTUP  PACKETS  LAYER 


START_ACK 

NONE 

A  FLAG  USED  TO  START  THE  GENERATION  OF  AN  ACKNOWLEDGE. 
PACKET. 

EXECUTE  ACC/ACK  PACKETS  LAYER 


DATA  ELEMENT  NAME:  START_ADD_GET 

ALIASES:  NONE 


VALUES  AND  MEANINGS 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


A  FLAG  USED  TO  START  THE  GENERATION  OF  A  CONTROL  ADD_GET_ 
PACKET. 

GENERATE  CONTROL  PACKETS  LAYER 


START  _ADD_PUT 
NONE 

A  FLAG  USED  TO  START  THE  GENERATION  OF  A  CONTROL  ADD_PUT 
PACKET. 

GENERATE  CONTROL  PACKETS  LAYER 


STARTJUTTRIB/ACK 

NONE 

A  FLAG  USED  TO  START  THE  GENERATION  OF  AN  ATTRI B / ACK_PACKE T . 
EXECUTE  ACC/ACK  PACKETS  LAYER 


START ^ATTRIBUTES 
NONE 

A  FLAG  WHICH  IS  ISSUED  WHEN  FIRST_CONFIGURATION_FLAG  IS 
SET  AND  WE  RECEIVE  A  CONFIGURATION  PACKET.  IT  STARTS 
GENERATION  OF  THE  FIRST  ATTRIBUTES_PACKET. 

EXECUTE  STARTUP  PACKETS  LAYER 


START_CONNECT 

NONE 

A  FLAG  USED  TO  START  THE  GENERATION  OF  A  CONTROL.CONNECT. 
PACKET. 

GENERATE  CONTROL  PACKETS  LAYER 


START_CONNECT_ACK 

NONE 

A  FLAG  MEANING  THAT  A  VALID  CONTROL_CONNECT_PACKET  HAS 
BEEN  RECEIVED,  THEREFORE  ISSUE  AN  ACKNOWLEDGE_PACKET . 
EXECUTE  ACC/ACK  PACKETS  LAYER 

EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 
EXECUTE  CONTROL  PACKETS  LAYER 
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DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


START_ER/ECF_COMP 
S  TART^C  C/COMP 

A  FLAG  USED  TO  START  THE  GENERATION  OF  AN  ACCESS_COMPLETE_ 
PACKET. 

EXECUTE  ACC/ACK  PACKETS  LAYER 


START_KEY_GET 

NONE 

A  FLAG  USED  TO  START  THE  GENERATION  OF  A  CONTROL  KEY_GET 
PACKET. 

GENERATE  CONTROL  PACKETS  LAYER 


START_KEY_PUT 

NONE 

A  FLAG  USED  TO  START  THE  GENERATION  OF  A  CONTROL  KEYJPUT 
PACKET. 

GENERATE  CONTROL  PACKETS  LAYER 


START_SEQ_PUT_AP  PEND 
NONE 

i 

A  FLAG  USED  TO  START  THE  GENERATION  OF  A  CONTROL  SEQ_PUT_ 
PACKET.  .} 

GENERATE  CONTROL  PACKETS  LAYER 


START_SEQ_GET 

NONE 

A  FLAG  USED  TO  START  THE  GENERATION  OF  A  CONTROL  SEQ_GET. 
PACKET. 

GENERATE  CONTROL  PACKETS  LAYER 


DATA  FLOW  NAME 

ALIASES: 

COMPOSITION: 


STARTUP_ERRORS 

NONE 


NOTES 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


STARTUP_ERRORS  =  RECEIVED  JVC CESS_COMPLETE_ERRORS 
EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 


STARTUP_PACKETS 

NONE 

ST  ARTU  P_PACKE  TS  =  T~ ACCESS_COMPLETE_PACKET~I 

I  ATTRI B/ACK_PACKET  I 

I  ACRNOWLEDGE_PACKET  | 

I  AC  CE  S S_PACKE  T  I 

EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 


STATU S_PACKETS 
NONE 


STATUSJPACKETS 


RECE IVED_CONTRQL_ERRORS 

RECE I VED_UNSUPPO  RT_ST ATU  S  2 

RECEIVED_FORMAT_STATUS2 

RECE IVED_STATU  S_ERROR 

SETUP_ERRORS 

EOF 

FILE_ERRORS 
SUCCESSFUL_OPERATION 
OPE RATION_IN_PROGRES S 


=  OPERATOR  +  TYPE =9  +  STSCODE  +  RFA  + 
RECNUM  +  STV 

CODE  ARCHITECTURE  PACKETS  LAYER 


STREAMID 

NONE 

THE  STREAM  IDENTIFICATION  FIELD.  THIS  FIELD  IS  USED  TO 
ALLOW  A  SINGLE  USER  TO  HAVE  MULTIPLE  DATA  STREAMS  IN  USE 
FOR  A  SINGLE  OPEN  FILE.  ALL  DATA  STREAMS  USE  THE  SAME 
LOGICAL  LINK  (MULTIPLEX  ON  THE  STEAMID  NUMBER) . 

ALL  ARCHITECTURE  LAYERS 


STSCODE 

NONE 

STATUS  FIELD  =  MACCODE  =  THE  MACRO  OR  FUNCTIONAL  GROUP 
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NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES : 

VALUES  AND  MEANINGS: 


REASON  FOR  THE  ERROR. 

MICCODE  =  THE  SPECIFIC  REASON  FOR  THE  ERROR. 
ALL  ARCHITECTURE  LAYERS 


STV 

NONE 

SECONDARY  STATUS.  USED  TO  RETURN  SECONDARY  STATUS 
INFORMATION  SUCH  AS  DEVTCE  ERROR  CODES,  ETC. 

ALL  ARCHITECTURE  LAYERS 


SUBMIT_AS_COMMAND_FILE 

NONE 

REQUEST  IN  THE  ACCESS_PACKET  THAT  REQUESTS  THAT  A  STORE 
OPERATION  BE  DONE  ON  THE  DATA  THAT  FOLLOWS  IN  A  TEMPORARY 
FILE  AND  THAT  THIS  FILE  BE  SUBMITTED  TO  A  BATCH-TYPE 
FACILITY  UPON  ACCESS  COMPLETION.  THE  FILE  WILL  BE  DELETED 
FOLLOWING  EXECUTION  BY  THE  BATCH  FACILITY.  THE  FILE  IS 
TRANSFERRED  USING  SEQUENTIAL  FILE  STORAGE. 

EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 


SUCCESSFUL_OPERATION 

RECEIVEr_SUCCESSFUL_OPERATION 

SEE  ALIASES 

EXECUTE  CONTINUE  PACKETS  LAYER 
CODE  ARCHITECTURE  PACKETS  LAYER 


SYSCAP 

NONE 

GENERIC  SYSTEM  CAPABILITIES  SUCH  AS; 

1.  SUPPORTS  SEQUENTIAL  FILE  ORGANIZATION 

2.  SUPPORTS  RELATIVE  FILE  ORGANIZATION 
’  3.  SUPPORTS  FILE  PREALLOCATION 

4.  SUPPORTS  SEQUENTIAL  FILE  ACCESS 

5.  SUPPORTS  RANDOM  ACCESS  BY  RECORD  NUMBER 

6.  SUPPORTS  RANDOM  ACCESS  BY  VIRTUAL  BLOCK  NUMBER 

7.  SUPPORTS  APPEND  TO  FILE  ACCESS 

8.  SUPPORTS  COMMAND  FILE  SUBMISSION  AND/OR  EXECUTION 

9.  SUPPORTS  MULTIPLE  DATA  STREAMS 
10.  SUPPORTS  STATUS  RETURN  AND 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 
NOTES : 

DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 
NOTES : 

DATA  FLOW  NAME: 


11.  SUPPORST  BLOCKING  OF  PACKETS 
ALL  ARCHITECTURE  LAYERS 


TIMEOUT 

RECEIVED_TIMEOUT 
SEE  ALIASES 

CODE  ARCHITECTURE  PACKETS 


TYPE 

NONE 

THE  TYPE  OF  PACKET.  REFER  TO  EACH  INDIVIDUAL  MESSAGE 
FOR  ITS  TYPE. 

ALL  ARCHITECTURE  LAYERS 


VALID_RECEIVED_AC  CES  S_COMPLETE_PACKET 
AC  CE  S  S_COMPLETE_PACKET 
RECEIVED  _^AC  CE  S  S_COMPLETE_PACKET 
RECE IVED^AC COMP ( COMMAND ) 

RECE I VED_AC  COMP ( PURGE ) 

RECE  I  VED_,AC COMP  (  RESPONSE  ) 

RECEIVED  COMP( EOS) 

SEE  ALIASES 

EXECUTE  ACC/ACK  PACKETS  LAYER 


VALID_RECEIVED  _ACCESS_PACKET 

ACCESS_PACKET 

RECEIVED  JIlC  CE  S  S_PACKET 

AC  CES  S ( ERAS  E )  .PACKET 

AC  CE  S  S  ( RENAME )  _JPACKET 

AC  CES  S(ECF)  JACKET 

AC CES S(SCF) .PACKET 

SEE  ALIASES 

EXECUTE  STARTUP  PACKETS  LAYER 
EXECUTE  ACC/ACK  PACKETS  LAYER 

EXECUTE  ARCHITECTURE  PROTOCOL  AT  PRIMARY  NODE  LAYER 


VALID_RECEIVED.ACKNOWLEDGE_PACKET 


ALIASES: 

COMPOSITION: 

NOTES: 


DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES : 


DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


ACKNOWLEDGE_PACKET 

RECE IVED_ACKNOWLEDGE_PACKET 

SEE  ALIASES 

EXECUTE  STARTUP  PACKETS  LAYER 
GENERATE  CONTROL  PACKETS  LAYER 


VAL ID_RECE I VED_ATTRI BUT  ES_PACKET 

ATTRIBUTES_PACKET 

RECEIVED_ATTRIBUTES_PACKET 

SEE  ALIASES 

EXECUTE  STARTUP  PACKETS  LAYER 


VALID_RECEIVED_CONFIGURATION_PACKET 
CONFIGURATION_PACKET 
RECEIVED_CONFI GURATION_PACKET 

SEE  ALIASES 

EXECUTE  STARTUP  PACKETS  LAYER 


VALID_RECEIVED_STATUS_PACKET 

RECEIVED_STATUS_PACKET 

SEE  ALIASES 

DECODE  STATUS  PACKETS  LAYER 


VERSION 

NONE 

A  FIELD  IDENTIFYING  THE  PROTOCOL  AND  SOFTWARE  VERSION 
NUMBERS. 

ALL  ARCHITECTURE  LAYERS 


WORKING_PACKETS 

NONE 

WORKING_PACKETS  =  |  SETUP_PACKETS  I 

I  DATA^PACKETS  I 

I  CONTROL_PACRETS  I 

I  CONTINUE_INTERRUPT_PACKET  I 
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N0TES{  CODE  ARCHITECTURE  PACKETS  LAYER 
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FILE  OR  DATABASE  NAME:  LOCAL_DATAwFILE 
ALIASES:  NONE 

COMPOSITION: 

THE  MEMORY  USED  TO  READ,  WRITE,  AND  DELETE  FILES  AT 
THIS  NODE. 

STANDARD  MEMORY 

EXECUTE  CONTINUE  PACKETS  LAYER 


ORGANIZATION 
NOTES : 


t 

PROCESS  NAME:  DECODE  ARCHITECTURE  PACKETS 

PROCESS  NUMBER:  1.1 

PROCESS  DESCRIPTION: 

IF  Input  type  code  =  9  then 

Output  as  RECEIVED_STATUS_PACKET 
ELSEIF  Input  type  code  =  8  then 
Output  as  RECEIVED_DATA_FILE 
ELSEIF  Input  type  code  =  7  then 

Output  as  RECEIVED^ACCESS_COMPLETEwPACKET 
ELSEIF  Input  type  code  =  1,  2,  3.  or  6  then 
Output  as  RECE I VED_STARTU P_P ACRE TS 
ELSEIF  Input  type  code  =  5  then 

Output  as  RECEIVED_CONTINUE_PACKETS 
ELSEIF  Input  type  code  =  4  then 

Output  as  REC E I VED_CONTROL_PACKE  TS 
ELSE  output  as  ACCEPT_CONFIRM 


PROCESS  NAME:  CHECK  FOR  ERRORS 

PROCESS  NUMBER:  1.2.1 

PROCESS  DESCRIPTION: 

ON  a  RECEIVED_STATUS_PACKET 

IF  errors  exist  in  packet  then 

Output  as  RECEIVED__STATUS_ERROR 
ELSE  output  as  VAL ID_REC I EVED_STATU S_PACKE T 


PROCESS  NAME:  DECODE  MACCODE  FIELD 

PROCESS  NUMBER:  1.2.2 

PROCESS  DESCRIPTION: 

IF  Input  MACCODE  value  =  0  then 

Output  as  RECEIVED_PENDING_STATUS 
ELSEIF  Input  MACCODE  value  =1  then 

Output  as  RECEIVED_SUCCESSFUL_STATUS 
ELSEIF  Input  MACCODE  value  =  2  then 

Output  as  RECEIVED_UNSUPPORTED_STATUS 
ELSEIF  Input  MACCODE  value  =  4  then 
Output  as  RECEIVED_FILE_STATUS 
ELSEIF  Input  MACCODE  value  =  5  then 
Output  as  RECEIVED JFORMAT_STATUS 
ELSE  Input  MACCODE  value  =  6  then 
Output  as  RECE I VED_SYNC_STATU S 


PROCESS  NAME:  DECODE  UNSUPPORTED  MICCODE  FIELD 

PROCESS  NUMBER:  1.2.3 

PROCESS  DESCRIPTION: 

IF  Input  MICCODE  value  =  0  then 

Output  as  RECEIVED_UNSUPPORT_MISC 
ELSEIF  Input  MICCODE  value  =  1  then 

Output  as  RFJEIVED_UNSUPPORT_CONFIG 
ELSEIF  Input  MISCODE  value  =  2  then 

Output  as  RECIEVED_UNSUPPORT_ATTRIB 
ELSEIF  Input  MICCODE  value  =  3  then 

Output  as  RECE IVED_UNSUP PO RT_AC CESS 
ELSEIF  Input  MICCODE  value  =  4  then 

Output  as  RECE IVED_UNSUP PO RT_CONT INUE 
ELSEIF  Input  MICCODE  value  =  5  then 

Output  as  RECE IVED_UN SUP  PO  RT_CONT  ROL 
ELSEIF  Input  MICCODE  value  =  6  then 
Output  as  REC E I V ED_UN SUP PO RT_AC K 
ELSEIF  Input  MICCODE  value  =  7  then 

Output  as  RECEIVED_UNSUPPORT_JlCC/COMP 
ELSEIF  Input  MICCODE  value  =  8  then 

Output  as  RECEIVED_UNSUPPORT_DATA 
ELSE  Input  MICCODE  value  =  9  then 

Output  as  RECEIVED_UNSUPPORT_STATUS2 


PROCESS  NAME:  DECODE  PENDING  MICCODE  FIELD 

PROCESS  NUMBER:  1.2.4 

PROCESS  DESCRIPTION: 

IF  Input  MICCODE  value  =  0  then 

Output  as  RECE I VED_OPE RATION_IN_PROGRES S 
ELSE  Null 


PROCESS  NAME:  DECODE  FORMAT  MICCODE  FIELD 

PROCESS  NUMBER:  1.2.5 

PROCESS  DESCRIPTION: 

IF  Input  MICCODE  value  =  0  then 

Output  as  RECEIVED_FORMAT_MISC 
ELSEIF  Input  MICCODE  value  =  1  then 
Output  as  RECEIVED_FORMAT_CONFIG 
ELSEIF  Input  MICCODE  value  =  2  then 
Output  as  RECEIVED_F0RMATJ1TTRIB 
ELSEIF  Input  MICCODE  value  =  3  then 
Output  as  RECEIVED_FO RMAT_AC CESS 
ELSEIF  Input  MICCODE  value  =  4  then 

Output  as  RECE I VED_FORMAT_CONT INUE 
ELSEIF  Input  MICCODE  value  =  5  then 

Output  as  RECEIVED_FORMAT_CONTROL 


ELSEIF  Input  MICCODE  value  =  6  then 
Output  as  RECEIVED_FORMAT_JACK 
ELSEIF  Input  MICCODE  value  =  7  then 

Output  as  RECEIVED_FORMAT^ ACC/COMP 
ELSEIF  Input  MICCODE  value  =  8  then 
Output  as  RECE I VED_FORMAT_DATA 
ELSE  Input  MICCODE  value  =  9  then 

Output  as  RECE IVED_FORMAT_STATU S 2 


PROCESS  NAME:  DECODE  FILE  MICCODE  FIELD 

PROCESS  NUMBER:  1.2.6 

PROCESS  DESCRIPTION: 

IF  Input  MICCODE  value  =  0  then 

Output  as  RECEIVED_FILE_ERRORS 
ELSE  Input  MICCODE  value  =  1  then 
Output  as  RECEIVED_TIMEOUT 


PROCESS  NAME:  DECODE  SYNC  MICCODE  FIELD 

PROCESS  NUMBER:  1.2.7 

PROCESS  DESCRIPTION: 

IF  Input  MICCODE  value  =  0  then 

Output  as  RECE IVED_SYNC_CONFIG 
ELSEIF  Input  MICCODE  value  =  1  then 
Output  as  RECE IVED_SYNC_ATTRI B 
ELSEIF  Input  MICCODE  value  =  2  then 
Output  as  RECE IVED_SYNC_AC CESS 
ELSEIF  Input  MICCODE  value  =  3  then 
Output  as  RECE I VED_SYNC_CONTR OL 
ELSEIF  Input  MICCODE  value  =  4  then 
Output  as  RECEIVED_SYNC_CONT INUE 
ELSEIF  Input  MICCODE  value  =  5  then 
Output  as  RECEIVED_SYNC_ACK 
ELSEIF  Input  MICCODE  value  =  6  then 
Output  as  RECEIVED_SYNC^AC C/COMP 
ELSEIF  Input  MICCODE  value  =  7  then 
Output  as  RECEIVED_SYNC_DATA 
ELSEIF  Input  MICCODE  value  =  8  then 
Output  as  RECEIVED_SYNC_STATUS2 
ELSE  Input  MICCODE  value  =  9  then 

Output  as  RECEIVED_SYNC_UNKNOWN 


PROCESS  NAME:  DECODE  SUCCESSFUL  MICCODE  FIELD 

PROCESS  NUMBER:  1.2.8 

PROCESS  DESCRIPTION: 

IF  Input  MICCODE  value  =  0  then 


Output  as  RECIEVEDJOF 
ELSE  Input  MICCODE  value  =  1  then 

Output  as  RECEIVED_SUCCESSFULJ3PERATION 


PROCESS  NAME:  DECODE  CONTROL  TYPE 

PROCESS  NUMBER:  1.3.1 

PROCESS  DESCRIPTION: 

IF  Input  =  VALID__RECEIVED_ACKNOWLEDGE_PACKET  and  connect  flag  Is  not  set  then 
Output  a  START_CONNECT 

Set  the  connect  flag 

ELSEIF  Input  =  VALID_RECEIVED_JACKNOWLEDGE_PACKET  and  connect  flag  is  set  then 
Generate  the  following  outputs  according  to  the  file  process  to  be 
performed: 

Reset  the  connect  flag 

FILE-PROCESS  OUTPUT 


Sequential  file  storage 
Sequential  file  append 
Sequential  file  retrieval 
Keyed  record  retrieval 
Record  file  address  retrieval 
Keyed  record  storage 
Record  file  address  storage 
Submit  as  command  file 
ELSE  Input  =  STATU S_P ACRE T  then 

Output  above  start  command  depending  on  the 
Packet  MACCODE.  MICCODE  field  combination 


START_SEQ_PUT_APPEND 
START_SEQ_PUT  _AP PEND 
START_SEQ_GET 
START_KEY_GET 
START _ADD_GET 
START _JCEY_PUT 
START _ADD_PUT 
START_SEQ_PUT_APPEND 

value  passed  in  the  $catua_ 


PROCESS  NAME:  GENERATE  CONTROL  CONNECT  PACKET 

PROCESS  NUMBER:  1.3.2 

PROCESS  DESCRIPTION: 

IF  Input  =  START_CONNECT  then 
Output  CONNECT_PACKET 
ELSE  Null 


PROCESS  NAME:  GENERATE  CONTROL  SEQ-GET  PACKET 

PROCESS  NUMBER:  1.3.3 

PROCESS  DESCRIPTION: 

IF  Input  =  START_SEQ_GET  then 
Output  SEQ_GET_PACKET 
ELSE  Null 


PROCESS  NAME:  GENERATE  CONTROL  SEQ-PUT  PACKET 

PROCESS  NUMBER:  1.3.4 

PROCESS  DESCRIPTION: 

IF  Input  =  START_SEQ_PUT_JlPPEND  then 
Output  SEQ_PUT_PACKET 
ELSE  Null 


PROCESS  NAME:  GENERATE  CONTROL  KEY-GET  PACKET 

PROCESS  NUMBER:  1.3.5 

PROCESS  DESCRIPTION: 

IF  Input  =  START JCEY_GET  then 
Output  KEY_GET_PACKET 
ELSE  Null 


PROCESS  NAME:  GENERATE  CONTROL  KEY-PUT  PACKET 

PROCESS  NUMBER:  1.3.6 

PROCESS  DESCRIPTION: 

IF  Input  =  START_KEY_PUT  then 
Output  KEY_PUT_PACKE T 
ELSE  Null 


PROCESS  NAME.*  GENERATE  CONTROL  ADD-GET  PACKET 

PROCESS  NUMBER:  1.3.7 

PROCESS  DESCRIPTION: 

IF  Input  =  START_Jtf)D._GET  then 
Output  ADD_GET_PACKET 
ELSE  Null 


PROCESS  NAME:  GENERATE  CONTROL  ADD-PUT  PACKET 

PROCESS  NUMBER:  1.3.8 

PROCESS  DESCRIPTION: 

IF  Input  =  START_AUD_PUT  then 
Output  ADD_PUT_PACKET 
ELSE  Null 


PROCESS  NAME:  CODE  GET  FIELDS 

PROCESS  NUMBER:  1.3.9 

PROCESS  DESCRIPTION: 

IF  Input  =  SEQ_GETJPACKET,  REY_GET_PACKET,  or  ADD_GET  PACKET  then 
Output  *8  GET_PACKET 
ELSE  Null 


PROCESS  NAME:  CODE  PUT  FIELDS 

PROCESS  NUMBER:  1.3.10 

PROCESS  DESCRIPTION: 

IF  Input  =  SEQ_PUT_PACKET,  KEY_PUT_PACKET,  or  ADD_PUT_PACKET  then 
Output  as  PUT_PACKET 
ELSE  Null 


PROCESS  NAME:  CODE  CONTROL  FIELDS 

PROCESS  NUMBER:  1.3.11 

PROCESS  DESCRIPTION: 

IF  Input  =  GET_PACKET  or  PUT_PACKET  then 
Output  as  CONTRQL_PACKET 
ELSE  Null 


PROCESS  NAME:  GENERATE  CONFIGURATION  PACKET 

PROCESS  NUMBER:  1.4.1 

PROCESS  DESCRIPTION: 

IF  Input  =  PRIMARY_START_FILE_CONFIGURATION  and  ACCEPT_CONFIRM  or  input  = 
PRIMARY_START_FILE_CONFIGURAT ION  and  NEW^ACCESS  then 
Output  C ONFI GURAT I0N_PACKE T  and 
Output  FIR ST_C ONF I G_FLAG 

ELSE  Input  =  RECEIVED_SYNC_CONFIG.  RECEIVED_TIMEOUT ,  RECEIVED_FORMAT_CONFIG, 
RECEIVED_UNSUPPORT_CONFIG,  RECEIVED_FORMAT_ATTRIB ,  RECEIVED_FORMAT_ 
ACCESS,  or  SECOND_CONFIG_FLAG  then 
Output  CONFIGURATION_PACKET 


PROCESS  NAME:  CHECK  FOR  CONFIGURATION  ERRORS 

PROCESS  NUMBER:  1.4.2 

PROCESS  DESCRIPTION: 

IF  Input  contains  errors  then 

Output  RECEIVED_CONFIG_ERRORS 
ELSE  output  VALID_RECEIVED_CONFIGURATION_PACKET 


PROCESS  NAME:  DECODE  CONFIGURATION  FIELDS 

PROCESS  NUMBER:  1.4.3 

PROCESS  DESCRIPTION: 

IF  Input  SYSCAP  value  =  ERASE  or  RENAME  then 
Output  STARTs ACC_ER  flag 

ELSEIF  Input  SYSCAP  value  =  EXECUTE_COMMAND_FILE  or  SUBMIT_COMMAND_FILE  then 
Output  START_AC C_ECF  flag 


ELSEIF  FIRST_CONFIG_FLAG  is  set  and  BUFSIZ  is  large  enough  then 
Output  START JiTTRIB/ACC  flag 
Reset  FIRST_CONFIG_FLAG 

ELSEIF  FIRST_CONFIG_FLAG  is  set  and  BUFSIZ  is  small  then 
Output  START^ATTRIBUTES  flag 
Reset  FIRST_CONFIG_FLAG 
ELSE  FIRST_CONFIG_FLAG  is  not  set  then 
Output  a  SECOND_CONFIG_FLAG 


PROCESS  NAME:  GENERATE  ATTRIBUTES/ACCESS  PACKET 

PROCESS  NUMBER:  1.4.4 

PROCESS  DESCRIPTION: 

IF  Input  =  START_ATTRIB/ACC  or  RECEIVED_TIMEOUT  then 
Output  a  ATTRIB/ACC_PACKET 
ELSE  Null 


PROCESS  NAME:  GENERATE  ACCESS  ERASE,  RENAME  PACKET 

PROCESS  NUMBER:  1.4.5 

PROCESS  DESCRIPTION: 

IF  Input  =  START_ACC_ER  or  RECEIVED_TIMEOUT  and  ERASE  is  indicated  then 
Output  an  ACC/ER_PACKET  to  erase 

ELSE  Input  =  START_AC C_ER  or  RECEIVED_TIMEOUT  and  RENAME  is  indicated  then 
Output  an  ACC/ER_PACKET  to  rename 


PROCESS  NAME:  GENERATE  ACCESS  ECF/SCF  PACKET 

PROCESS  NUMBER:  1.4.6 

PROCESS  DESCRIPTION: 

IF  Input  =  START_ACC_ECF/SCF  or  RECEIVED_TIMEOUT  and  ECF  is  indicated  then 
Output  an  EXECUTE_COMMAND_FILE  ACC/ECF/SCF_PACKET 
ELSE  Input  =  START_ACC_ECF  or  RECEIVED_TIMEOUT  and  SCF  is  indicated  then 
Output  a  SUBMIT  COMMAND  FILE  ACC/ECF/SCF_PACKET 


PROCESS  NAME:  GENERATE  ATTRIBUTES  PACKET 

PROCESS  NUMBER:  1.4.7 

PROCESS  DESCRIPTION: 

IF  Input  =  START_ATTRIBUTES  then 
Output  FIRST_ATTRIB_FLAG 
Output  ATTRIBUTES_PACKET 
ELSEIF  Input  =  SECOND JVTTRIB.FLAG  then 
Output  ATTRIBUTES_PACKET 

ELSE  Input  =  RECEIVED_UNSUPPORT^ATTRIB,  RECEIVED_SYNC_ATTRIB,  or  RECEIVED. 
TIMEOUT  then 

Output  ATTRIBUTES.PACKET 
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Reset  FIRST_ATTRIB_FLAG 


PROCESS  NAME:  CHECK  FOR  ACKNOWLEDGE  ERRORS 

PROCESS  NUMBER:  1.4.8 

PROCESS  DESCRIPTION: 

IF  Input  =  RECEIVED_ACKNOWLEDGE_PACKET  and  no  errors  exist  then 
Output  VALID_RECEIVED _ACKNOWLEDGE_PACKET 
ELSEIF  Input  =  RECEIVED^ ACKNOWLEDGE_PACKET  with  errors  then 
Output  RECE IVED^ACK_ERRORS 

ELSEIF  Input  =  RECEIVED_ATTRIB/ACK_PACKET  and  errors  exist  then 
Output  RECEIVED _ACK_ERRORS 

ELSEIF  Input  =  RECEIVED_ATTRIB/ACK_PACKET  and  no  errors  exist  and  ATTRIB/ACK. 
ERROR_FLAG  is  not  set  then 

Output  VALID_RECEIVED _ACKNOWLEDGE_PACKET 
ELSE  ATTRIB/AC^ERROR^FLAG  is  set  then  null 


PROCESS  NAME:  CHECK  FOR  ATTRIBUTES  ERRORS 

PROCESS  NUMBER:  1.4.9 

PROCESS  DESCRIPTION: 

IF  Input  =  RECEIVED_ATTRIBUTES_PACKET  and  no  errors  exist  then 
Output  VALID_RECEIVED _ATTRIBUTES_PACKET 

ELSEIF  Input  =  RECEIVED_JATTRIBUTES_PACKET  and  errors  exist  then 
Output  RECEIVED_ATTRIB_ERRORS 

ELSEIF  Input  =  RECEIVED_ATTRIB/ACK_PACKET  and  errors  exist  then 
Output  ATTRIB/ ACK_ERROR  flag 
Output  RECEIVED_ATTRIB_ERRORS 

ELSEIF  Input  =  RECEIVED_ATTRIB/ACC_PACKET  and  errors  exist  then 
Output  ATTRIB/ACC_ERROR  flag 
Output  RECEIVED_ATTRIB_ERRORS 

ELSE  Input  =  RECEIVEDJVTTRIB/ACK_PACKET  or  RECEIVED_ATTRIB/ACC_PACKET  and 
no  errors  exist  then  null 


PROCESS  NAME:  CHECK  FOR  ACCESS  ERRORS 

PROCESS  NUMBER:  1.4.10 

PROCESS  DESCRIPTION: 

IF  Input  =  RECEIVED_ACCESS_PACKET  with  no  error  then 
Output  VALID_RECEIVED_ACCESS_PACKET 
ELSEIF  Input  =  RECEIVED^ACCES_PACKET  with  errors  then 
Output  RECEIVED_ACC_ERRORS 

ELSEIF  Input  =  RECE IVED_ATTRI B / AC C_PACKE T  with  no  errors  and  ATTRIB/ AC C_F,RROR 
flag  is  not  set  then 

Output  VALID_RECEIVED_ACCESS_PACKET 

ELSEIF  Input  =  RECE I VED^ATTRI B / AC C_PACKE T  with  errors  and  the  ATTRIB/ACC_ERROR 
flag  is  not  set  then 

Output  RECEIVED_ACC_ERRORS 
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ELSE  Input  =  ATTRIB/ACC_ERROR  then  null 


PROCESS  NAME:  DECODE  ATTRIBUTES  FIELDS 

PROCESS  NUMBER:  1.4.11 

PROCESS  DESCRIPTION: 

IF  Input  =  VALID_RECEIVEDJVTTRIBUTES_PACKET  and  FIRST_ATTRIB_FLAG  is  not  aet 
then 

Output  S ECOND^ATTRI B_FLAG 

ELSE  Input  =  VALID_RECEIVED_ATTRIBUTES_PACKET  and  FIRST_ATTRIB_FLAG  is  set 
then 

Output  START_AC CESS 
Reset  FIRST-ATTRIB_FLAG 


PROCESS  NAME:  CODE  SETUP  ERRORS 

PROCESS  NUMBER:  1.4.12 

PROCESS  DESCRIPTION: 

IF  Input  =  RECEIVED_CONFIG_ERRORS ,  RECEIVED_ACK_ERRORS, 

RECEIVED_ATTRIB_ERRORS,  RECE IVED_ACC_ERRORS .  or  RECEIVED_ACCESS. 
COMPLETE_ERRORS  then 
Output  as  SETUP_ERRORS 
ELSE  Null 


PROCESS  NAME:  CODE  SETUP  PACKETS 

PROCESS  NUMBER:  1.4.13 

PROCESS  DESCRIPTION: 

IF  Input  =  ACCES S_COMPLETE_PACKET .  ATTRIB/ACKJPACKET,  ACKNOWLEDGE_PACKET, 
ACCESS_PACKET,  ACC/ER_PACKET,  CONFIGURATIONJPACKET,  ACC/ECF/SCF. 
PACKET.  ATTRIB / AC C_PACKET .  or  ATTRIBUTES_PACKET  then 
Output  as  S ETU P_PACKE TS 
ELSE  Null 


PROCESS  NAME:  GENERATE  ACCESS  PACKET 

PROCESS  NUMBER:  1.5.1 

PROCESS  DESCRIPTION: 

IF  Input  =  RECEIVED_TIMEOUT,  RECEIVED JJPSVRRORT .ACCESS,  RECEIVED_SYNC_ACCESS, 
or  START_ACCESS  then 
Output  ACCES S_PACKET 
ELSE  Null 


PROCESS  NAME:  DECODE  ACCESS  FIELDS 
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PROCESS  NUMBER:  1.5.2 

PROCESS  DESCRIPTION: 

IF  Input  ACCFUNC  value  =  open  or  create  AND  ATTRIB/ACC_PACKET  was  received 
then 

Output  START__ATTRIB/ACK  flag 

ELSEIF  Input  ACCFUNC  value  =  open  or  create  and  ATTRIB/ACC_PACKET  was  not 
received  then 

Output  START_ACK  flag 

ELSEIF  Input  ACCFUNC  value  =  rename,  erase,  or  execute  command  file  then 
Output  START_ER/ECF_COMP  flag 
ELSEIF  Input  ACCFUNC  value  =  directory- list  then 
Output  START_ACC/COMP  flag 
ELSE  Input  ACCFUNC  value  =  submit  command  file  then 
Output  SUBMIT^AS_COMMAND_FILE 


PROCESS  NAME:  GENERATE  ACCESS  COMPLETE  PACKET 

PROCESS  NUMBER:  1.5.3 

PROCESS  DESCRIPTION: 

IF  Input  =  START_ER/ECF_COMP ,  START J1C C/COMP,  RECEIVED_AC COMP (COMMAND) , 

RECE IVED^AC COMP ( PURGE ) ,  or  RECEIVED_ACCOMP(PURGE)  in  conjunction 
with  a  RECEIVED_CONTINUE_ABORT_PACKET  then 
Generate  and  Output  an  ACCESS_COMPLETE_PACKET(RESPONSE) 

ELSEIF  Input  =  ACCOMP(EOS)  then 

Output  an  AC CES S_COMPLETE_PACKET ( EOS ) 

ELSEIF  Input  =  AC COMP (COMMAND)  or  RECEIVED_EOF  then 
Output  an  AC CE S S_COMPLETE_PACKET( COMMAND ) 

ELSEIF  Input  =  ACCOMP(PURGE)  then 

Output  an  AC  CES  S_COMPLETE_PACKET ( PURGE ) 

ELSE  Input  =  RECE IVED_FORMAT_JlC C/COMP,  RECEIVED_UNSUPPORT_ACC/COMP.  RECEIVED. 
SYNC^AC C/COMP,  or  RECEIVED_TIMEOUT  then 
Output  the  appropriate  ACCESS_COMPLETE_PACKET 


PROCESS  NAME:  GENERATE  ACKNOWLEDGE  PACKET 

PROCESS  NUMBER:  1.5.4 

PROCESS  DESCRIPTION: 

IF  Input  =  RECEIVED  JTIMEOUT,  START  ..CONNECT  _^CR,  RECE  I  VED_U  ^SUPPORT _ACK, 
RECEIVED_SYNC_ACK .  RECE IVED_FORMAT— ACK .  or  START_ACK  then 
Output  an  ACKNOWLEDGE_PACKET 
ELSE  Null 


PROCESS  NAME:  CHECK  FOR  ACCESS  COMPLETE  ERRORS 

PROCESS  NUMBER:  1.5.5 

PROCESS  DESCRIPTION: 

IF  Input  =  RECEIVED^ACCESS_COMPLETE_PACKET  with  no  errors  then 
Output  a  VALID_RECEIVED_AC  CE S  S_COMPLETE_PACKET 
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ELSE  Input  =  RECEIVED _ACCESS_COMPLETE_PACKET  with  errors  then 
Output  a  RECE IVED^AC CE S S_COMPLETE_ERRORS 


PROCESS  NAME:  DECODE  CMPFUNC  FIELDS 

PROCESS  NUMBER:  1.5.6 

PROCESS  DESCRIPTION: 

IF  Input  CMPFUMC  value  =  terminate  then 
Output  RECE I VED_AC COMP ( COMMAND ) 

ELSEIF  Input  CMPFUNC  value  =  response  then 
Output  RECEIVED_AC COMP (RESPONSE) 

ELSEIF  Input  CMPFUNC  value  =  end  of  stream  then 
Output  RECEIVED_jVCCOMP(EOS) 

ELSE  Output  RECEIVEDJVC COMP (PURGE) 


PROCESS  NAME:  GENERATE  ATTRIB/ACK  PACKET 

PROCESS  NUMBER:  1.5.7 

PROCESS  DESCRIPTION: 

IF  Input  =  RECE IVED_TIME OUT  or  START^ATTRIB/ ACK  then 
Output  a  ATTRI B/ ACR_PACKE T 
ELSE  Null 


PROCESS  NAME:  DECODE  CONTROL  PACKET 

PROCESS  NUMBER:  1.6.1 

PROCESS  DESCRIPTION: 

IF  Input  =  RECEIVED_CONTROL_PACKET  with  errors  then 
Output  RECEIVED_CONTROL_ERRORS 
ELSEIF  Input  CTLFUNC  value  =  connect  then 
Output  RECE  I  VED__CONNECT_PACKE  T 
ELSEIF  Input  CTLFUNC  value  =  get  then 
Output  RECE IVED_GET_P ACRE T 

ELSE  Input  CTLFUNC  value  =  put,  delete,  update,  or  rewing  then 
Output  RECEIVED_PUTJPACKET 


PROCESS  NAME:  DECODE  CONNECT  FIELDS 

PROCESS  NUMBER:  1.6.2 

PROCESS  DESCRIPTION: 

IF  Input  +  RECEIVED_CONNECT_PACKET  then 
Decode  the  fields  and 

Output  a  START— CONNECT _ACK  flag 


ELSE  Null 


PROCESS  NAME:  DECODE  GET  FIELDS 

PROCESS  NUMBER:  1.6.3 

PROCESS  DESCRIPTION: 

IF  Input  RAC  field  =  sequential  file  access  or  sequential  record  access  or 

block  mode  file  transfer  then 
Output  RECEIVED_SEQ_GET_PACKET 
ELSEIF  Input  RAC  field  =  keyed  access  then 
Output  RECE IVED_£EY_GET_PACKE T 
ELSE  Input  RAC  field  =  access  by  record  file  address  then 
Output  RECEIVED_ADD_GET_PACKET 


PROCESS  NAME:  DECODE  PUT  FIELDS 

PROCESS  NUMBER:  1.6.4 

PROCESS  DESCRIPTION: 

IF  Input  RAC  field  =  sequential  file  access  or  sequential  record  access  or 

block  mode  file  transfer  then 
Output  RECE IVED_SEQ_PUT_PACKE T 
ELSEIF  Input  RAC  field  =  keyed  access  then 
Output  RECEIVEDJCEY_PUT_PACKET 
ELSE  Input  RAC  field  =  access  by  record  file  address  then 
Output  RECEIVED _ADD_PUT_PACKET 


PROCESS  NAME:  DECODE  ON  NEXT  ACTION 

PROCESS  NUMBER:  1.7.1 

PROCESS  DESCRIPTION: 

IF  Input  =  RECEIVED_SEQ_GET_PACKET  or  RECEIVED_KEY_GET_PACKET  then 
Send  out  the  data  in  the  correct  format 
ELSEIF  Input  =  RECEIVED_ADD_GET_PACKET  then 

Send  out  the  data  one  record  at  a  time  between  reception  of  the  RECEIVED. 
SUCCESSFUL_OPERATION  status  packet 
ELSEIF  Input  =  RECEIVED_CONTINUE_ONLY_PACKET  then  either 
Resend  the  bad  data  record  and  continue  or  just 
Continue  sending  data  records. 

ELSEIF  Input  =  RECEIVED_CONTINUE_SKIP_PACKET  then 

Skip  over  the  bad  record  and  continue  sending  data  records 
ELSEIF  Input  =  errors  in  any  of  the  above  inputs  then 
Output  FILE_ERRORS 

ELSEIF  Input  =  RECEIVED_SYNC_DATA,  RECEIVED_FILE_ERRORS,  RECEIVED_FORMAT_ 
DATA,  RECEIVED_UNSUPPORT .DATA  then 

IF  want  to  skip  the  bad  record  and  continue  then 
Output  SKIP.REC/CONTINUE 

ELSEIF  want  to  continue  with  the  bad  record  still  in 
the  file  then 

Output  CONT INUE_WITH_BAD_REC 
ELSEIF  want  to  purge  the  new  file  and  terminate  then 
Output  ACCOMP(PURGE)  immediately  followed  by 
Output  PURGE/ABORT_INTERRUPT 
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ELSE  want  to  close  the  new  file  and  terminate  then 
Output  AC COMP (COMMAND)  immediately  followed  by 
Output  PRUGE/ABORT_INTERRUPT 

ELSEIF  want  to  stop  a  sequential  file  storage  operation  before  it  is  complete 
and  purge  the  incomplete  file  then 
Output  PURGE /ABO RT_INT E RRUPT 

ELSEIF  want  to  send  a  message  to  let  the  accessing  system  know  there  will  be  a 
delay  in  getting  data  then 

Output  OPERATION_IN_PROGRESS 

ELSE  end-of-file  is  detected  and  want  to  end  the  data  stream  but  not  the 
logical  link  then 

Output  ACCOMP(EOS) 


PROCESS  NAME:  DECODE  ON  REQUIRED  ACTION 

PROCESS  NUMBER:  1.7.2 

PROCESS  DESCRIPTION: 

IF  Input  =  RECEIVED_DATA_FILE  with  errors  or  RECEIVED_FILE_ERRORS  then 
Output  either  DATA_ERRORS  or  FILE_ERRORS  or 

IF  want  to  request  link  termination  then 
Output  AC COMP (COMMAND) 

ELSEIF  want  to  request  data  stream  termination  then 
Output  AC COMP (EOS) 

ELSEIF  want  to  request  the  information  be  sent  again  then 
Output  RESENT_INFO 

ELSE  want  to  ship  that  record  and  continue  then 
Output  SKIP_INFO/ CONTINUE 

ELSEIF  Input  =  RECEIVED_DATAWFILE  and  RECE I VED_S EQ_PUT_PACKET  or  RECEIVED^ 
KEY_PUT_PACKET  or  SUBMIT_AS_COMMAND_FILE  then 
Output  data  to  file  in  correct  format 
ELSEIF  Input  =  RECEIVED_DATA_FILE  and  RECEIVED _JADD_PUT_PACKET  then 

Output  data  to  file  in  correct  format  and  after  each  store  operation 
Output  SUCCESSFUL_OPERATION 

ELSE  Input  =  RECEIVED_OPERATION_IN_PROGERSS  then  do  not 
Output  FILE_ERRORS  or  DATA_ERRORS 


PROCESS  NAME:  GENERATE  CONTINUE  ABORT  PACKET 

PROCESS  NUMBER:  1.7.3 

PROCESS  DESCRIPTION: 

IF  Input  =  PURGE/ABORT_INTERRUPT  or  CONTINUE_ABORT_ERROR  then 
Output  CONTINUE^ABORT_PACKET 
ELSE  Null 


PROCESS  NAME:  GENERATE  CONTINUE  SKIP  PACKET 

PROCESS  NUMBER:  1.7.4 

PROCESS  DESCRIPTION: 
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IF  Input  =  SKIP_REC /CONTINUE,  SKIP_INFO/CONTINUE,  or  CONTINUE_SKIP_ERROR  then 
Output  CONTINUE_SKIP_PACKET 
ELSE  Null 


PROCESS  NAMES  GENERATE  CONTINUE  ONLY  PACKET 

PROCESS  NUMBERS  1.7.5 

PROCESS  DESCRIPTIONS 

IF  Input  =  CO  NT IN UE_WI TH_BAD_REC ,  RESEND_INFO,  or  CONTINUE_ONLY_ERROR  then 
Output  CONTINUE_ONLY_PACKET 
ELSE  Null 


PROCESS  NAME:  CODE  CONTINUE  PACKETS 

PROCESS  NUMBER:  1.7.6 

PROCESS  DESCRIPTION: 

IF  Input  =  CONT INUE_JABORT_PACKET ,  CONTINUE_SKIP_PACKET,  or  CONTINUE_ONLY_ 
PACKET  then 

Output  as  CONTINUE_INTERRHPT_PACKET 
ELSE  Null 


PROCESS  NAME:  GENERATE  DATA  PACKET 

PROCESS  NUMBER:  1.7.7 

PROCESS  DESCRIPTION: 

IF  Input  =  DATA  then 

Generate  and  output  a  DATA_PACKET 
ELSE  Input  =  DATA  +  EOF  then 

Generate  and  output  last  DATA_PACKET  and 
Output  EOF  flag 


PROCESS  NAME:  CODE  CONTINUE  ERRORS 

PROCESS  NUMBER:  1.7.8 

PROCESS  DESCRIPTION: 

IF  Input  =  RECEIVED_UNSUPPORT_CONTINUE,  RECEIVED_FORMAT_CONTINUE,  or  RECEIVED_ 
SYNC_CONTINUE  then 

IF  CONTINUE_ABORT_PACKET  was  the  last  continue  packet  sent  then 
Output  CONTINUE_ABORT_ERROR 

ELSEIF  CONTINUE_SKIP_PACKET  was  the  last  continue  packet  sent  then 
Output  CONT INUE_SKI P_ERROR 

ELSE  CONTINUE_ONLY_PACKET  was  the  last  continue  packet  sent  then 
Output  CONTINUE_ONLY_ERROR 


ELSE  Null 


PROCESS  NAME:  START/ STOP  TIMER 

PROCESS  NUMBER:  1.8.1 

PROCESS  DESCRIPTION: 

IF  Input  =  RECEIVED_CONFIGURATION_PACKET,  RECEIVED_ATTRIBUTES_PACKET, 

RECE IVED_ACCES S_PACKET >  RECE I V ED_ATTRI B/ AC C_PACKE T ,  ACCESS. 
COMPLETE_PACKET( RESPONSE),  or  SETUP.ERRORS  then 
START  TIMER 

ELSEIF  Input  =  CONFIGURATION.PACKET,  ATTRIBUTES.PACKET,  ACKNOW LEDGE.PACKE T , 
RECEIVED_CONFIGURATION_PACKET,  LINK.TERMINATION,  or  RECEIVED. 
STARTUP_PACKETS  then 

STOP  TIMER 
ELSE  output  TIMEOUT 


PROCESS  NAME:  CODE  WORKING  PACKETS 

PROCESS  NUMBER:  1.8.2 

PROCESS  DESCRIPTION: 

IF  Input  =  SETUP.PACKETS ,  DATA.PACKETS ,  CONTROL.PACKETS ,  or  CONTINUE. 
INT E RKUPT.PACKE TS  then 
Output  WORKING.PACKETS 
ELSE  Null 


PROCESS  NAME:  GENERATE  STATUS  PACKETS 

PROCESS  NUMBER:  1.8.3 

PROCESS  DESCRIPTION: 

IF  Input  =  RECEIVED_CONTROL_ERRORS ,  RECEIVED.UNSUPPORT.STATUS2 ,  RECEIVED. 

FORMAT.STATUS2,  RECEIVED.SYNC.STATUS2 ,  SETUP.ERRORS,  EOF,  FILE. 
ERRORS,  SUC CE S SFUL.OPE RATION ,  OPERATION.IN.PROGRESS,  RECEIVED. 
STATU S.ERROR ,  DATA.ERRORS,  or  CONTINUE.ERRORS  then 
Output  appropriate  status  packet  as  STATUS.PACKET 
ELSE  Null 


PROCESS  NAME:  TERMINATE  LOGICAL  LINK 

PROCESS  NUMBER:  1.8.4 

PROCESS  DESCRIPTION: 

IF  Input  =  TIMEOUT,  RECEIVED.UNSUPPORT.MISC,  RECEIVED.FORMAT.MISC ,  RECEIVED. 
SYNC.UNKNOWN,  or  DISCONNECT  then 
Output  DISCONNECT.REQUEST 
ELSE  Null 


PROCESS  NAME:  TERMINATE  DATA  STREAM 

PROCESS  NUMBER:  1.8.5 

PROCESS  DESCRIPTION: 

IF  Input  =  RECE IVEDJ1C COMP (EOS)  then 
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IF  want  to  start  new  access  then 
Output  NEW^ ACCESS 
ELSE  output  DISCONNECT 
ELSE  Input  =  RECEIVED  J1C  COMP  (RESPONSE)  then 
Output  DISCONNECT 


PROCESS  NAME:  CODE  FILE  PACKETS 

PROCESS  NUMBER:  1.8.6 

PROCESS  DESCRIPTION: 

IF  Input  =  DISCONNECT_REQUEST,  WORKING_PACKETS,  or  STATUS_PACKETS  then 
Output  as  OUTGOING_PRI MARY_NODE_ARCHI TECTU RE_PACKE T 
ELSE  Null 


PROCESS  NAME:  CHECK  FOR  CONTINUE  ERROR 

PROCESS  NUMBER:  1.9 

PROCESS  DESCRIPTION: 

IF  Input  =  CONTINUE_PACKETS  with  errors  then 
Output  CONTINUE_ERRORS 
ELSEIF  Input  CONFUNC  value  =  try  again  then 
Output  as  RECE IVED_CONT INUE_ONLY_PACKE T 
ELSEIF  Input  CONFUNC  value  =  skip  then 

Output  as  RECE IVED_CONT INUE_SKI P_PACKET 
ELSE  Input  CONFUNC  value  =  abort  then 

Output  as  RECEIVED_CONTINUE„ABORT_PACKET 


PROCESS  NAME:  EXECUTE  ARCHITECETURE  PROTOCOL  AT  SECONDARY  NODE 

PROCESS  NUMBER:  2.0 

PROCESS  DESCRIPTION: 

Provide  standardized  formats  and  procedures  for  accessing  and  passing 
data  between  a  user  process  and  a  file  system  existing  in  a  network 
enviroment. 


255 


F 


1 


DATA  DICTIONARY 

FOR  TRANSPORT/NETWORK  LEVEL  (T/N)  PROTOCOL 


Contents 

Data  Element  /  Flow  Descriptions.... 

File  Definitions..... . 

Process  Specifications . . . . 


Page 

257 

299 

306 


256 


4 


4  * 


DATA  ELEMENT  NAME: 
ALIASES : 

VALDES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
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NOTES : 


DATA  ELEMENT  NAME: 
ALIASES : 

VALDES  AND  MEANINGS: 


ABORT 

NONE 

A  FLAG  DSED  TO  INDICATE  THAT  THE  RECEIVED_DISCONNECT_ 
INITIATE_PACKET  IS  A  RESDLT  OF  AN  ABORT_COMMAND .  RESDLTS 
IN  THE  IMMEDIATE  GENERATION  OF  A  DISCONNECT.CONFIRM. 
PACKET. 

EXECDTE  DISCONNECT  PACKET  LAYER 


ABORT_COMMAND 

NONE 

OPERATOR  OR  DIALOGDE  COMMAND  DSED  TO  ABORT  A  LOGICAL  LINK 
CONNECTION,  DIALOGDE  DATA  IS  NOT  SAVED,  CDRRENT  DIALOGUE 
DATA  BEING  TRANSMITTED  IS  LOST. 

EXECDTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 
EXECDTE  INCOMING  DIALOGDE  MESSAGE  LAYER 
EXECDTE  DIALOGDE  SEGMENT  LAYER 
EXECUTE  CONTROL  PACKET  LAYER 
EXECUTE  CONNECT  PACKET  LAYER 


AC  CEPT_CONFI RM 
NONE 

A  FLAG  DSED  TO  SET  THE  LINKJUXES SABLE  BIT  IN  THE 
ADJACENT_NODE_PARA METERS  TABLE.  THIS  INDICATES  THAT  THE 
LOGICAL.LINK  HAS  BEEN  SUCCESSFUL  CONNECTED. 

EXECUTE  CONNECT  PACKET  LAYER 


AC  CEPT_CONNECT 
NONE 

FLAG  USED  TO  INDICATE  THE  ACCEPTANCE  OF  A  RECEIVED. 
CONNECT_INITIATE_PACKET .  RESULTS  IN  THE  GENERATION  OF  A 
CONNECT_CONFIRM_PACKET . 

EXECDTE  CONNECT  PACKET  LAYER 


ACCOUNT 

NONE 

A  CHARACTER-CODED  DEFINITION  THAT  WHEN  PAIRED  WITH  THE 
REQUESTOR-ID  IDENTIFIES  A  "BILLING  ADDRESS”  FOR  SERVICE 
COSTS  AT  THE  DESTINATION  NODE. 
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NOTES 


ALL  TRANSPORT  LAYERS 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES : 

VALDES  AND  MEANINGS: 


NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


ACKNDM 

NONE 

THE  NDMBER  OF  THE  LAST  TRANSPORT  DATA  SEGMENT 
SDCCESSFDLLY 

RECEIVED  AND  AN  ACK  OR  NAK  INDICATION.  THIS  FIELD  IS 
OPTIONAL.  ITS  PRESENCE  IS  INDICATED  BY  BIT  15  BEING  SET. 
FORMAT: 

QOAL  =  ACK  =  ACKNOWLEDGE 

NAK  =  NEGATIVE  ACKNOWLEDGE 
NDMBER  =  THE  SEGMENT  NDMBER 
ALL  TRANSPORT  LAYERS 


ACKNDM I 
NONE 

THE  NDMBER  OF  THE  LAST  TRANSPORT  INTERRDPT  OR  LINK 
SERVICE  PACKET  SDCCESSFDLLY  RECEIVED  AND  AN  ACK  OR  NAK 
INDICATION.  THIS  FIELD  IS  OPTIONAL.  ITS  PRESENCE  IS 
INDICATED  BY  BIT  15  BEING  SET. 

FORMAT: 

QUAL  =  ACK  =  ACKNOWLEDGE 

NAK  =  NEGATIVE  ACKNOWLEDGE 
NDMBER  =  THE  PACKET  NDMBER 
ALL  TRANSPORT  LAYERS 


ADJACENT_NODE_PACKETS 

NONE 

AD JACENT_NODE_PACK  E  TS  = 

I  TRANSMITTED_TRANSPORT_INITIALIZATION_PACKET  I 

I  FIRST_DISCONNECT_CONFIRM_PACKET  I 

I  TRAN SM I TTED_TRAN SPORT_DATA_PACKET  I 

I  TRANSMITTED_TRANSPORT_ACKNOWLEDGE_PACKET  I 

I  TRAN  SM ITTED_TRAN  SPORT_CONTR  OL_PACKE  T  I 

I  (EXCEPT  FOR  CONNECT_INITIATE)  I 

=  WHERE  DSTADDR  IMPLYS  THAT  THE 
PACKET  IS  GOING  TO  AN  ADJACENT 
NODE.  INITIALIZATION  PACKETS 
ALWAYS  ARE  BETWEEN  ADJACENT  NODES 
ONLY. 
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NOTES 


EXECUTE  OUTGOING  TRANSPORT  PACKET  LAYER 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES : 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES : 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


ADJACENT_NODE_ROUT ING_PACKET 

ROUTING_PACKET 

VAL ID_ROUT ING_PACKE T 

HOPPED_ROUTING_PACKET 

INITIAL_ROUTE_PACKET 

OLD_ROUTING_PACKETS 

SEE  ALIASES 

EXECUTE  NETWORK  PROTOCOL  AT  PRIMARY  NODE  LAYER 


BLKSIZE 

NONE 

THE  MAXIMUM  PHYSICAL  BLOCK  SIZE  THE  LINK  WILL  ACCEPT. 
ALL  TRANSPORT  LAYERS 


CHOKE 

NONE 

BIT  INDICATES  THAT  THE  PACKET  IS  A  CHOKE  PACKET  RATHER 
THAN  AN  ORDINARY  DATA  PACKET.  NOT  PRESENTLY  USED. 

ALL  NETWORK  LAYERS 


CLOSED_FLOW_CONTROL 

NONE 

A  FLAG  THAT  INDICATES  THAT  THE  FLOW_CONTROL_PARA METER 
DATA_FLOW_CONTROL_SWITCH  IS  SET  TO  CLOSED  RESULTING  IN 
ALL  INCOMING  DATA  PACKETS  BEING  NEGATIVELY  ACKNOWLEDGED. 
EXECUTE  DATA  PACKET  LAYER 


COMMVER 

NONE 

THE  VERSION  OF  THE  COMMUNICATIONS  PART  OF  THE  TRANSPORT 
PROTOCOL. 

ALL  TRANSPORT  LAYERS 


4 
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DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


CONNECT_CONFIRM_PACKET 

RECEIVEL_CONNECT_CONFIRM_PACKET 

CONNECT_CONFIRM_PACKET  =  MSGFLG  +  DSTADDR  t  SRCADDR  + 

SEGMENT  REQUESTS  COUNTS  +  INFO  + 
SEGSIZE  +  DSTNAME  +  SRC NAME  + 
MENU  +  RQSTRID  +  PASSWRD  + 
ACCOUNT 

EXECUTE  CONNECT  PACKET  LAYER 


CONNECT_INITIATE_PACKET 

RECEIVED_CONNECT_INITIATE_PACKET 

CONNECT_INITIATE_PACKET  =  MSGFLG  +  DSTADDR=0  +  SRCADDR  + 

SEGMENT  REQUEST  COUNT  +  INFO  + 
SEGSIZE  +  DSTNAME  +  SRCNAME  + 
MENU  +  RQSTRID  +  PASSWRD  + 
ACCOUNT 

EXECUTE  CONNECT  PACKET  LAYER 


CONNECT_REQUEST 

NONE 

OPERATOR  OR  DIALOGUE  COMMAND  TO  START  CONNECTION  OF  THE 
LOGICAL  LINK. 

EXECUTE  DIALOGUE  SEGMENT  LAYER 

EXECUTE  CONNECT  PACKET  LAYER 

EXECUTE  CONTROL  PACKET  LAYER 

EXECUTE  INCOMING  DIALOGUE  MESSAGE  LAYER 

EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 


CORRECT_PAS  SWORD 
NONE 

THE  RECEIVED  CORRECT  PASSWORD 
EXECUTE  STARTUP  PACKET  LAYER 


CORRECT  JPAS  SWORD_COMMAND 
RECEIVED_CORRECT_PAS  SWORD_COMMAND 

A  COMMAND  TO  NOTIFY  THE  SATELLITE  NODE  THAT  THE  PASSWORD 
GIVEN  IN  THE  NODE_VERIFICATION_PACKET  WAS  CORRECT. 
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NOTES : 

DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 

NOTES : 

DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES : 

DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


LOGICAL  LINK  ESTABLISHMENT  CAN  NOW  PROCEED.  ADJACENT 
NODE_PARAMETER  TABLE  VALUES  ARE  NOW  VALID. 

EXECUTE  STARTUP  PACKET  LAYER 


COUNT  ED_TRAN SP  0  RT_DAT  A_S EGMENT 

INCOMING_DIALOGUE_DATA 

NORMAL_DATA_PACKET 

VALID_NORMAL_.DATA_SEGMENT 

RECEIVED_NORMAL_DATA_SEGMENT 

INCOMING_DIALOGUE_SEGMENT 

TRANSPORT_DATA_SEGMENT 

P IGGYBACKED_TRAN SPO RT_DATA_SEGMENT 

TRAN  SM I T  T ED_DA  TA_PACK E  T 

RETRAN SMITTED_DATA_PACKE T 

SEE  ALIASES  ’ 

EXECUTE  DIALOGUE  SEGMENT  LAYER 


COUNT  ED.JTRAN  SPO  RT_I  /  L_PACK  E  T 
TRANSPORT_I/L_PACKET 
RETRAN SMITTED_I/L_PACKET 
TRAN  SMITTED_I /L_PACKET 

COUNT  ED_TRAN  SP  ORT_I /L_PACKE  T  = 

T~ INTERRUPT_LINK_SERVICES_PACKET  f 
I  DATA_LINK_SERVICES_PACKET  I 


EXECUTE  I/L  PACKET  LAYER 


DATA 

NONE 

THE  DATA  THE  DIALOGUE  PROCESS  WISHES  TO  SEND  OVER  A 
LOGICAL  LINK.  THIS  INFORMATION  WILL  BE  TOTALLY 
TRANSPARENT  AND  MAY  BE  ALL  8-BITS  OF  EACH  BYTE.  DATA 
PACKETS  ARE  LIMITED  TO  THE  MAXIMUM  SEGSIZE  ALLOWED  ON  THE 
LOGICAL  LINK  IN  THE  DIRECTION  THAT  THE  PACKET  IS  SENT. 

THE  LENGTH  OF  THE  DATA  FIELD  IS  ASCERTAINED  FROM  THE 
TOTAL  LENGTH  OF  THE  NORMAL  DATA  SEGMENT  AND  CONSIST  OF 
ALL  BYTES  IN  THE  SEGMENT  AFTER  THE  SEGNUM  FIELD.  THE 
DATA  FIELD  MAY  BE  NULL. 

ALL  TRANSPORT  LAYERS 
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DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES : 


DATA_ACK_FLAG 

NONE 

FLAG  USED  TO  START  THE  GENERATION  OF  AN  ACKNOWLEDGEMENT 
PACKET  ON  A  RECIEVED  DATA  PACKET. 

EXECUTE  DATA  PACKET  LAYER 


DATA_ACK_PACKET 
DA  TA_NAK_PACKET 

DATA_ACK_PACKET  =  MSGFLG  +  DSTADDR  +  SRCADDR  +  ACKNUM 

EXECUTE  DIALOGUE  SEGMENT  LAYER 

EXECUTE  INCOMING  DIALOGUE  MESSAGE  LAYER 

EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 

EXECUTE  DATA  PACKET  LAYER 


DATA_FLOW_ERROR 

NONE 

INDICATES  TirL.T  THE  FLOW_CONTROL_PARA METER  TABLE  CONTAINED 
A  CLOSED  DATA_FLOW_CONTROL_SWITCH  OR  THE  DATA_REQUEST_ 
COUNT  HAD  BEEN  OVERFLOWED. 

EXECUTE  DIALOGUE  SEGMENT  LAYER 
EXECUTE  INCOMING  DIALOGUE  MESSAGE  LAYER 


DATA  I 
NONE 

THE  DATA  TO  BE  SENT  OVER  A  LOGICAL  LINK.  THIS  FIELD  IS 
TOTALLY  TRANSPARENT  AND  MAY  USE  ALL  8-BITS  OF  EACH  BYTE. 
THE  LENGTH  OF  THE  DATA  FIELD  IS  ASCERTAINED  FROM  THE 
TOTAL  LENGTH  OF  THE  INTERRUPT  PACKET  AND  CONSIST  OF  ALL 
BYTES  IN  THE  PACKET  AFTER  THE  SEGNUMI  FIELD. 

ALL  TRANSPORT  LAYERS 


DA  T A_L INK_SERVICES_PACKET 

INTERRUPT_LINK_SERVICES_PACKET 

VALID_LINK_SERVICES_PACKET 

SEE  ALIASES 

EXECUTE  I/L  PACKET  LAYER 
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DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES : 


DA  T  A_NAK_FLAG 
NONE 

FLAG  USED  TO  START  THE  GENERATION  OF  AN  NEGATIVE 
ACKNOWLEDGEMENT  PACKET  ON  A  RECEIVED  DATA  PACKET. 
EXECUTE  DATA  PACKET  LAYER 


DATA_NAK_PACKE  T 
DATA_ACK_PACKET 

SEE  ALIASES 

EXECUTE  DIALOGUE  SEGMENT  LAYER 
EXECUTE  INCOMING  DIALOGUE  MESSAGE  LAYER 
EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 
EXECUTE  DATA  PACKET  LAYER 


DESTINATION 

NONE 

THE  NAME  OF  THE  NODE  TO  WHICH  THE  ROUTING  PACKET  IS 
GOING. 

ALL  NETWORK  LAYERS 


DISCONNECT_CONFIRM_PACKET 

FIRST_DISCONNECT_CONFIRM_PACKET 

RECEIVED_DISCONNECT_CONFIRM_PACKET 

SEE  ALIASES 

EXECUTE  CONTROL  PACKET  LAYER 
EXECUTE  CONNECT  PACKET  LAYER 
EXECUTE  DISCONNECT  PACKET  LAYER 


DIS  CONNECT_INIT IATE_PACKET 
RECEIVED_DISCONNECT_INITIATE_PACKET 

DISCONNECT_INITIATE_PACKET  =  MSGFLG  +  DSTADDR  +  SRCADDR  + 

DISCONNECT  REASON  +  DSTNAME 
+  SRCNAME  +  MENU  +  RQSTRID  + 
PASSWRD  +  ACCOUNT 

EXECUTE  CONNECT  PACKET  LAYER 
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DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS 


DISCONNECT_REQUEST 

NONE 


OPERATOR  OR  DIALOGUE  COMMAND  USED  TO  STOP  THE  LOGICAL 
LINK  PROCESS.  CURRENT  DIALOGUE  DATA  IS  TRANSMITTED  AND 
ACKNOWLEDGED  BEFORE  THE  DISCONNECT_REQUEST  IS  ALLOWED  TO 
TAKE  EFFECT. 

NOTES:  EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 

EXECUTE  INCOMING  DIALOGUE  MESSAGE  LAYER 
EXECUTE  DIALOGUE  SEGMENT  LAYER 
EXECUTE  CONTROL  PACKET  LAYER 
EXECUTE  CONNECT  PACKET  LAYER 


DATA  ELEMENT  NAME:  DISCONNECT_REQUIRED 

ALIASES:  NONE 

VALUES  AND  MEANINGS: 

A  FLAG  USED  TO  INDICATE  THAT  THE 
SATELLITE_NODE_PARA METERS  TABLE  IS  NOT  SET  TO 
THE  CORRECT  PASSWORDS  AND  THAT  THE 
LINK  IS  NOT  UP  AND  RUNNING. 

NOTES:  DECODE  ROUTE  HEADER  LAYER 


DATA  ELEMENT  NAME:  DSTADDR 

ALIASES:  NONE 

VALUES  AND  MEANINGS: 

THE  LOGICAL  LINK  DESTINATION  ADDRESS  FOR  THE  PACKET. 
THIS  ADDRESS  IS  ASSIGNED  WHEN  A  LINK  IS  EXTABLISHED 
(CONNECT_PACKETS) . 

NOTES:  ALL  TRANSPORT  LAYERS 


DATA  ELEMENT  NAME:  DSTNAME 

ALIASES :  NONE 

VALUES  AND  MEANINGS: 

THE  DESTINATION  PROCESS  IDENTIFICATION. 

FORMAT  02: 

OBJTYPE  =  OBJECT  TYPE 
GRPCODE  =  BINARY  GROUP  CODE 
USRCODE  =  BINARY  USER  CODE 

DESCRPT  =  PROCESS  DESCRIPTOR.  A  UNIQUE  NAME  THAT 
QUALIFIES  THE  OBJECT  TYPE. 

FORMAT  01: 

OBJTYPE  =  OBJECT  TYPE 
DESCRPT  =  PROCESS  DESCRIPTOR 
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NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 


NOTES : 


FORMAT  00: 

OBJTYPE  =  OBJECT  TYPE 

RULES: 

APPLICATION  PROGRAMS  =  FORMAT  01  OR  02 
DIALOGUE  LEVEL  PROTOCOL  =  FORMAT  00 
SOURCE  PROCESS  DESCRIPTOR  =  FORMAT  02 
ALL  TRANSPORT  LAYERS 


ENTER_MAINTENANCE_MODE 

NONE 

REFER  TO  DATA  DICTIONARY  FOR  LINK  LEVEL  PROTOCOL 
EXECUTE  DIALOGUE  SEGMENT  LAYER 


ERROR_REASON 

NONE 

REFER  TO  FILE  “REASON” 

EXECUTE  DISCONNECT  PACKET  LAYER 
EXECUTE  CONTROL  PACKET  LAYER 

EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 


FCVAL 

NONE 

THE  NUMBER  OF  NORMAL  DATA  SEGMENTS  OR  INTERRUPT  PACKETS 
THAT  THE  SENDER  OF  THE  PACKET  CAN  RECEIVE  IN  ADDITION  TO 
THOSE  PREVIOUSLY  REQUESTED  BY  A  LINK  SERVICE  PACKET.  THIS 
NUMBER  IS  ADDED  TO  THE  REQUEST  COUNT  WHICH  IS  MAINTAINED 
IN  THE  FLOW_CONTROL_PARA METERS  TABLE  TO  DETERMINE  HOW 
MANY  NORMAL  DATA  SEGMENTS  OR  INTERRUPT  PACKETS  WILL  BE 
TRANSMITTED  VIA  A  LOGICAL  LINK. 

ALL  TRANSPORT  LAYERS 


FIRST_DISCONNECT_CONFIRM_PACKET 
RECEIVED_DI S CONNECT_CONFIRM_PACKET 
DISCONNECT_CONFIRM_PACKET 

FIRST_DISCONNECT_CONFIRM_PACKET  =  MSGFLG  +  DSTADDR  + 

SRCADDR  +  REASON 

DECODE  ROUTE  HEADER  LAYER 

EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 
EXECUTE  OUTGOING  TRANSPORT  PACKETS  LAYER 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME; 
ALIASES: 

VALUES  AND  MEANINGS 
NOTES : 


DATA  FLOW  NAME: 
ALIASES : 


COMPOSITION: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 


FLOW_CONTROL_ERRORS 

NONE 


FLOW  CONTROL_ERRORS  =  I  LINK_INACCES SABLE  I 

I  INTERRUPT_FLOW_ERROR  I 
I  DATA_FLOW_ERROR  I 


EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 


FUNCTIONS 

NONE 


THE  FUNCTIONS  SUPPORTED  AT  THIS  NODE. 

FORMAT: 

INT  =  INTERCEPT  FUNCTIONS 

=  000  =  NO  INTERCEPT  -  SET  ON  TRANSMIT  BY  A 

NON- INTERCEPT - SATELLITE 
NODE 

=  111  =  INTERCEPT  -  SET  ON  TRANSMIT  BY  A 


INTERCEPT-ROUTING-NODE 


ALL  TRANSPORT  LAYERS 


HOP_COUNT 

HOPS 

REFER  TO  ALIASES 
ALL  NETWORK  LAYERS 


HOPPED_ROUT ING_PACKET 

ROUTING_PACKET 

VAL ID_R0UT ING_PACKET 

INIT IAL_ROUT ING_PACKE T 

ADAJACENT_NODE_ROUTING_PACKET 

OL  D_ROUT IN G_P ACRE  TS 

SEE  ALIASES 

EXECUTE  NETWORK  PROTOCOL  AT  PRIMARY  NODE  LAYER 


HOPS 

HOP_COUNT 
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VALUES  AND  MEANINGS 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  FLOW  NAME: 
ALIASES : 
COMPOSITION: 

NOTES : 


DATA  FLOW  NAME: 
ALIASES : 


COUNTER  USED  TO  KILL  OFF  OLD  PACKETS. 
ALL  NETWORK  LAYERS 


I/L_ACK_FLAG 

NONE 

FLAG  USED  TO  START  THE  GENERATION  OF  AN  ACKNOWLEDGEMENT 
PACKET  ON  A  RECEIVED_I/L_PACKET. 

EXECUTE  DATA  PACKET  LAYER 


I/L_ACK_PACKET 

I/L_NAK_PACKET 

I/L_ACK_PACKET  =  MSGFLG  +  DSTADDR  +  SRCADDR  +  ACKNUMI 

EXECUTE  I/L  PACKET  LAYER 

EXECUTE  INCOMING  DIALOGUE  MESSAGE  LAYER 

EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 

EXECUTE  DATA  PACKET  LAYER 


I / L_NAK_FLAG 
NONE 

FLAG  USED  TO  START  THE  GENERATION  OF  AN  NEGATIVE 
ACKNOWLEDGEMENT  PACKET  ON  A  RECEIVED  I/L  PACKET. 
EXECUTE  DATA  PACKET  LAYER 


I/L_NAK_PACKET 
I / L_ACK_PACKE  T 

SEE  ALIASES 

EXECUTE  I/L  PACKET  LAYER 
EXECUTE  INCOMING  DIALOGUE  MESSAGE  LAYER 
EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 
EXECUTE  DATA  PACKET  LAYER 


INCOMING_DIALOGUE_DATA 

NORMAL_DATA_PACKET 

VAL  ID_NORMAL_DATAwSEGMENT 

RECE I  VED_NORMAL_DATAw_S  EGMENT 

INCOMING_DIALOGUE_SEGMENT 
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COMPOSITION: 


NOTES: 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 


NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


TRAN  SPORT_DATA_SEGMENT 
PIGGYBACKED_TRANSPORT_DATA_SEGMENT 
COUNT ED_TRANSPORT_DATA_SEGMENT 
TRAN  SMITTED_DATA_PACKE  T 
RETRAN  SMITTED  JDATA^PACKET 

INCOMING_DIALOGUE_DATA  =  MSGFLG  +  DSTADDR  +  SRCADDR  + 

ACKNUM  +  SEGNUM  +  DATA 
EXECUTE  DIALOGUE  SEGMENT  LAYER 


INCOMING_DIAL 0GUE_INT  ERRUPT 
TRANSPORT_INTERRUPT_PACKET 
P IGGYBACKED_TRAN  SP  0  RT_INT  ERRUPT_PACKE  T 
VALID_INTERRUPT_PACKET 

INCOMING_DIALOGUE_INTERRUPT  =  MSGFLG  +  DSTADDR  +  SRCADDR 

+ACKNUMI  +  SEGNUMI  +  DATAI 

EXECUTE  DIALOGUE  SEGMENT  LAYER 

EXECUTE  I/L  PACKET  LAYER 

EXECUTE  INCOMING  DIALOGUE  MESSAGE  LAYER 


INCOMING_DI ALOGUE_MES  SAGE 
SECONDARY_INCOMING_„DIALOGUE_MESSAGE 


INCOMING_DIALOGUE_MESSAGE  = 


INCOMING_DIALOGUE_PACKET 

OPERATOR_PAS SWORD_COMMAND 

CONNECT_REQUEST 

ENTER_MAINTENANCE_NODE 

OPERATOR_START_COMMAND 

ABORT_COMMAND 

DISCONNECT_REQUEST 


EXECUTE  DIALOGUE  SEGMENT  LAYER 
EXECUTE  INCOMING  DIALOGUE  MESSAGE  LAYER 
EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 
OVERVIEW  LAYER 


INCOMING_DIALOGUE_PACKET 

OUTGOING_DIALOGUE_DATAt_PACKET 

INCOMING_DIALOGUE_PACKET  = 


|  INCOMING_DIALOGUE_INTERRUPT  I 
I  INCOMING_DIALOGUE_DATA  I 
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NOTES 


EXECUTE  DIALOGUE  SEGMENT  LAYER 


r 

?  t 


DATA  FLOW  NAME; 
ALIASES: 


COMPOSITION: 


NOTES : 


DATA  FLOW  NAME; 

ALIASES: 

COMPOSITION: 


NOTES : 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION; 


NOTES : 


DATA  FLOW  NAME; 
ALIASES: 


COMPOSITION: 


INCOMING_DIALOGUE_SEGMENT 
INCOMING_DIALOGUE_DATA 
NO  RMAL_DATA_PACKET 
VALID_NORMAL_DATA_SEGMENT 
RECEIVED_NORMAL_DATA^SEGMENT 
TRAN SPORT_DATA_SEGMENT 
PIGGYBACKED_TRANSPORT_DATAy_SEGMENT 
COUNT ED_TRANSPORT_DATA_SEGMENT 
TRAN  SMITTED_DATAk_PACKET 
RETRAN  SMITTED_DATA_PACKE  T 

SEE  ALIASES 

EXECUTE  DIALOGUE  SEGMENT  LAYER 


IN  COMING_NODE_NE  TWORK_PACKE  T 
SECONDARY_INCOMING_NODE_NETWORK_PACKET 

INCOMING_NODE_NETWORK_PACKET  =  I  NETWORK_PACKET  | 

I  ROUTING_PACKET  | 

EXECUTE  NETWORK  PROTOCOL  AT  PRIMARY  NODE  LAYER 
OVERVIEW  LAYER 


INCOMING_NODE_TRAN  SPORT_PACKET 
INCOMING_SATELLITE_TRANSPORT_PACKET 
SECONDARY_INCOMING_SATELLITE_TRANSPORT_PACKET 
SECONDARY_INCOMING_NODE_TRANSPORT_PACKET 

SEE  ALIASES 
OVERVIEW  LAYER 

EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 
DECODE  ROUTE  HEADER  LAYER 

EXECUTE  NETWORK  PROTOCOL  AT  PRIMARY  NODE  LAYER 


INCOMING_SATELLITE_TRANSPORT_PACKET 

SECONDARY_INCOMING_SATELLITE_TRANSPORT_PACKET 

INCOMING_NODE_TRANSPORT_PACKET 

SECOND ARY_INCOMING_NODE_TRANSPORT_PACKET 

INCOMING_SATELLITE_TRANSPORT_PACKET  = 


I 


NOTES : 


DATA  ELEMENT  NAME: 
..LIASES : 

VALDES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 

AT  TASES : 

V/lL JES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES : 

VALDES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 


I  ODTGOING_TRANSPORT_RODTE_PACKET 
I  RECIEVED_ADJACENT_NODE_PACKETS 
I  VALID_DSTNODE_CI_PACKET 
I  INVALID_DSTNODE_PACKETS 
I  VAL ID_DSTN ODE_PACKE  TS 


OVERVIEW  LAYER 

EXECDTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 
DECODE  ROUTE  HEADER  LAYER 


INCORRECT_PAS SWORD_COMMAND 

RECE I VED_INC  0  RRECT_PAS  SWO  RD_C  OMMAND 

A  COMMAND  TO  NOTIFY  THE  SATELLITE  NODE  THAT  THE  PASSWORD 
GIVEN  IN  THE  NODE_VERIFICATION_PACKET  WAS  INCORRECT. 
BEFORE  LOGICAL  LINK  ESTABLISHMENT  CAN  PROCEED  MDST  START 
INITIALIZATION  PROCEDURE  OVER  WITH  CORRECT  PASSWORD. 
EXECUTE  STARTUP  PACKET  LAYER 


INFO 

NONE 

INFORMATION.  FORMAT: 

PRI  =  LINK  PRIORITY  NOT  USED  AT 
PRESENT. 

ALL  TRANSPORT  LAYERS 


INITIAL IZE_LINK 
NONE 

REFER  TO  DATA  DICTIONARY  FOR  LINK  LEVEL  PROTOCOL. 
EXECUTE  STARTUP  PACKET  LAYER 


INITIALIZATION_COMPLETE 

NONE 

REFER  TO  DATA  DICTIONARY  FOR  LINK  LEVEL  PROTOCOL. 
EXECUTE  STARTUP  PACKET  LAYER 


INITIZATION_ON_OTHEF_END 

NONE 
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VALUES  AND  MEANINGS 


NOTES : 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 


NOTES : 


REFER  TO  DATA  DICTIONARY  FOR  LINK  LEVEL  PROTOCOL. 
EXECUTE  STARTUP  PACKET  LAYER 


INITIAL_ROUTE_PACKET 

ROUTING_PACKET 

VAL  ID_ROUT  ING_PACKE  T 

HOP  PED_ROUT ING_PACKE  T 

AD JACENT_NODE_ROUT ING_PACKE T 

OLD_ROUT  ING_PACKE  TS 

SEE  ALIASES 

EXECUTE  NETWORK  PROTOCOL  AT  PRIMARY  NODE  LAYER 


INTERRUPT_ERROR 

NONE 

FLOW  CONTROL  FAILURE  =  INTERRUPT  MESSAGE  RECEIVED  WHEN 
THE  INTERRUPT  REQUEST  COUNT  IS  ZERO. 

EXECUTE  DATA  PACKET  LAYER 
EXECUTE  CONTROL  PACKET  LAYER 
EXECUTE  CONNECT  PACKET  LAYER 

EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 


INTERRUPT_FLOW_ERROR 

NONE 


INDICATES  THAT  IN  THE  FLOW_CONTROL_PARA METERS  TABLE  THAT 
THE  INTERRUPT_REQUEST_COU NT  HAD  BEEN  OVERFLOWED. 

EXECUTE  I/L  PACKET  LAYER 

EXECUTE  INCOMING  DIALOGUE  MESSAGE  LAYER 


INTERRUPT_LINK_SERVICES_PACKET 
DATA^_LINK_SERV  ICE  S_PACKE  T 

valid_link_services_packet 

INTERRUPT_LINK_SERVICES_PACKET  =  MSGFLG  +  DSTADDR  + 

SRCADDR  +  ACKNUMI  + 
SEGNUMI  +  LSFLAGS  + 
FCVAL 

EXECUTE  I/L  PACKET  LAYER 
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DATA  ELEMENT  NAME:  INVALID_DSTADDR_PACKETS 

ALIASES:  NONE 

VAi  S  AND  MEANINGS: 

A  FLAG  USED  TO  INDICATE  THAT  THE  DSTADDR  FIELD  WITHIN  THE 
MSGFLG  FIELD  DOES  NOT  CONTAIN  AN  ADDRESS  OF  A  REACHABLE 
LOGICAL  LINK  FROM  THIS  NODE. 

NOTES:  DECODE  ROUTE  HEADER  LAYER 


DATA  ELEMENT  NAME: 
ALIASES : 

VALUES  AND  MEANINGS: 


NOTES : 


INVALID_DSTNODE_PACKETS 

NONE 

FLAG  USED  TO  INDICATE  THAT  THE  DESTINATION  CODE  WITHIN 
THE  RTRDR  FIELD  IS  NOT  EQUAL  TO  THE  NAME  OF  A  REACHABLE 
SATELLITE  FROM  THIS  NODE. 

DECODE  ROUTE  HEADER  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS : 
NOTES : 


LINE_COST 

NONE 

WEIGHT  OF  A  PARTICULAR  PHYSICAL  LINK. 
ALL  NETWORK  LAYERS 


DATA  ELEMENT  NAME:  LINK_INACCES SABLE 

ALIASES:  NONE 

VALUES  AND  MEANINGS: 

A  FLAG  TFAT  INDICATES  THAT  THE  AD JACENT_NODE_PARA METERS 
TABLE  HAS  BEEN  SET  TO  A  L INK_INAC CE S SABLE  SINCE  THE 
PHYSICAL  LINK  OVER  WHICH  THE  ADJACENT  NODE  INITIALIZATION 
THAT  TOOK  PLACE  HAS  UNDERGONE  A  TRANSITION  OUT  OF  THE  ON 
STATE. 

NOTES:  EXECUTE  DIALOGUE  SEGMENT  LAYER 

EXECUTE  INCOMING  DIALOGUE  MESSAGE  LAYER 


DATA  ELEMENT  NAME:  LINK_SERVICES_ERROR 

ALIASES:  NONE 

VALUES  AND  MEANINGS: 

FLOW  CONTROL  VIOLATION  -  ILLEGAL  FCVAL 
NOTES:  EXECUTE  DATA  PACKET  LAYER 

EXECUTE  CONTROL  PACKET  LAYER 
EXECUTE  CONNECT  PACKET  LAYER 

EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 


I 
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DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


COUNT 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


LS_CODE 

NONE 

A  FLAG  USED  TO  INDICATE  THAT  A  TRANSMIT  BUFFER  WAS  NOT 
COMPLETELY  FULL  WHEN  THE  LAST  DATA  SEGMENT  WAS  PUT  INTO 
IT. 

EXECUTE  I/L  PACKET  LAYER 

EXECUTE  DATA  PACKET  LAYER 

EXECUTE  INCOMING  DIALOGUE  MESSAGE  LAYER 

EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 


LS FLAGS 
NONE 

LINK  SERVICE  FLAGS.  FORMAT: 

FCMOD  =  FLOW  CONTROL  MODIFICATION 
=  0  =  NO  CHANGE 
=  1  =  STOP  DATA 
=  2  =  START  DATA 
FCVAL  INT  =  INTERPRETATION  OF 
FCVAL  FIELD 

=  0  =  DATA  SEGMENT  COUNT 
=  1  =  INTERRUPT  REQUEST 


ALL  TRANSPORT  LAYERS 


MAXLNKS 

Nv,NE 

THE  MAXIMUM  NUMBER  OF  LINKS  THIS  NODE  WILL  SUPPORT.  THE 
VALUE  IS  LIMITED  TO  4096. 

ALL  TRANSPORT  LAYERS 


MENU 

NONE 

FIELD  FORMAT  CONTROL  =  RQSTRID,  PASSWORD,  ACCOUNT  FIELDS 
ALL  TRANSPORT  LAYERS 
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DATA  ELEMENT  NAME 


MSGDATA 


ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


i 


NONE 

DATA.  THE  REMAINDER  OF  A  TRANSPORT  PACKET 
ALL  TRANSPORT  LAYERS 


MSGFLG 

NONE 

00000000  =  MIDDLE  SEGMENT  OF  A  MULTI-SEGMENT  DIALOGUE 
MESSAGE 

00100000  =  THE  FIRST  SEGMENT  OF  A  MULTI-SEGMENT  DIALOGUE 
MESSAGE 

01000000  =  THE  LAST  SEGMENT  OF  A  MULTI-SEGMENT  DIALOGUE 
MESSAGE 

01100000  =  THE  ONLY  SEGMENT  OF  A  DIALOGUE  MESSAGE 
00110000  =  INTERRUPT  PACKET 
00010000  =  LINK  SERVICE  PACKET 

00000100  =  ACKNOWLEDGEMENT  OF  NORMAL  DATA  SEGMENT 
00010100  =  ACKNOWLEDGEMENT  OF  INTERRUPT  PACKET  OR  LINK 
SERVICES  PACKET 

00011000  =  CONNECT_INITIATE_PACKET 
00101000  =  CONNECT_CONFIRM_PACKET 
00111000  =  DISCONNECT_INITLATE_PACKET 
01001000  =  DISCONNECT_CONFIRM_PACKET 
01011000  =  NODE_INITIALIZATION_PACKET 
01011000  =  NODE_VE  RIFICATIO  N_PACKE  T 
00001000  =  NO  OPERATION  (NOP) 

ALL  TRANSPORT  LAYERS 


NODEAD DR 
NONE 

THE  SOURCE  MODE  ADDRESS.  THE  VALUE  OF  THIS  FIELD  MUST  BE 
GREATER  THAN  1  AND  LESS  THAN  241.  NO  TWO  NODES  IN  THE 
SAME  NETWORK  MAY  HAVE  THE  SAME  NODE  ADDRESS. 

ALL  TRANSPORT  LAYERS 


NODENAME 
RTHDR( srcnode ) 

SEE  ALIASES 

ALL  TRANSPORT  LAYERS 
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DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES : 


DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 


NETWORK  _PACKET 
NONE 

NE TWO RK_PACKE T  =  I  INCOMING_NODE_TRANSPORT_PACKET  I 
I  NETWORK_TO_NETWORK_PACKET  I 

EXECUTE  NETWORK  PROTOCOL  AT  PRIMARY  NODE  LAYER 


NETWORK_TO_NETWORK_PACKET 

VAL I D_NE  TWO  RK_T0_NE  TW 0  RK_PACKE  T 

VAL I  D_NE  TO  0  RK_PACKE  T 

NETWORK_TO_NETWORK_PACKET  =  TRANSPORT_PACKET  WITH  A 

DESTINATION  CODE  THAT  IS  NOT  ADJACENT  TO  THIS 
NODE. 

EXECUTE  NETWORK  PROTOCOL  AT  PRIMARY  NODE  LAYER 


NO_ABORT 

NONE 

A  FLAG  USED  TO  INDICATE  THAT  THE  RECEIVED_DISCONNECT. 
INITIATE_PACKET  IS  A  NORMALLY  GENERATED  DISCONNECT. 
RESULTS  IN  A  STOP_LINK  FLAG  BEING  ISSUED. 

EXECUTE  DISCONNECT  PACKET  LAYER 


NO_BUFFER_SPACE 

NONE 

FLAG  USED  TO  GENERATE  A  NEGATIVE  ACKNOWLEDGEMENT  SINCE 
THERE  WERE  NO  MORE  RECEIVE  BUFFERS  TO  LOAD  INCOMING  DATA 
PACKETS  INTO. 

EXECUTE  DATA  PACKET  LAYER 


NODE_INITIALIZATION_VO_FACKET 
RECEIVED_NODE_INITIALIZATION_PACKET 
RECEIVED_INTERCEFT_INITIALIZATTON_PACKET 
RECEIVED_NO_INTERCEPT_INITIALIZATION_PACKET 
NODE_INITIALIZATION_Vl_ PACKET 


NOTES 


SEE  ALIASES 

EXECUTE  STARTUP  PACKET  LAYER 
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DATA  FLOW  NAME: 
ALIASES : 


COMPOSITION: 

NOTES: 


NODE_INITIALIZATION_VlJPACKET 
RECEIVED JK)DE_INITIALIZATION_PACKET 
RECEIVED_INTERCEPT_INITIALIZATION_PACKET 
RECEIVED  JNO_INTERCEPT_INITIALIZATION_PACKET 
NODE_INITIALIZATION_VO_PACKET 

SEE  ALIASES 

EXECUTE  STARTUP  PACKET  LATER 


DATA  FLOW  NAME:  NODE_VERIFICATION_PACKET 

ALIASES :  RECEIVED^ NODE_VERIFICATION_PACKET 

COMPOSITION: 

SEE  ALIASES 

NOTES:  EXECUTE  STARTUP  PACKET  LAYER 


DATA  FLOW  NAME:  NONADJACENT_NODE_PACKETS 

ALIASES:  NONE 

COMPOSITION: 

NONADJACENT_NODE_PACKETS  = 

T TRANSMITTED_TRANSPORTJlCKNOWLEDGE_PACKET~7 
I  FIRST_DISCONNECT_CONFIRM_PACKET  I 

I  TRANSMITTED_TRANSPORT_CONTROL_PACKET  I 
I  REAN  SMITTED_TRAN  SPO  RT_DATA_PACKET  I 

=  WHERE  THE  DSTADDR  IMPLYS  THAT 
THE  PACKET  IS  GOING  TO  A  NON- 
AD  JACENT  NODE.  IF  A  CONNECT. 
IN I T IATE_PACKE T  THEN  ALWAYS 
GIVES  THIS  ROUTE. 

NOTES:  EXECUTE  OUTGOING  TRANSPORT  PACKET  LAYER 


DATA  FLOW  NAME:  NONADJACENT_ROUTE_PACKET 

ALIASES :  OUTGOING_TRANSPORT_ROUTE_PACKET 

OUTGOING_NODE_TRANSPORT_PACKET 

SECONDARY_OUTGOING_NODE_TRANSPORT_PACKET 

TRANSPORT_RACKET 

COMPOSITION: 

NONDAJACENT _ROUTE_PACKET  =  CONTAINS  A  RTHDR  FIELD  THAT 

HAS  A  DSTNODE  NAME  THAT  IS 
REFERING  TO  A  SATELLITE  THAT 
IS  NOT  ADJACENT  TO  THIS 
ROUTING  NODE. 

NOTES:  EXECUTE  OUTGOING  TRANSPORT  PACKETS  LAYER 
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EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 


DATA  FLOW  NAME: 
ALIASES : 
COMPOSITION: 


NOTES: 


NONADJACENT_SATELLITE_PACKETS 

NONE 

NONADJACENT_SATELLITE_PACKETS  =  RTHDRJJONADJACENTJJODE. 

PACKETS  -  NONADJACENT 
ROUTE_PACKET 

EXECUTE  OUTGOING  TRANSPORT  PACKETS  LAYER 


DATA  FLOW  NAME:  NORMALJDATA_PACKET 

ALIASES:  INCOMINGJDIALOGUEJDATA 

VALID_NORMAL_DATA_SEGMENT 
RECEIVED_NORMALJDATA_SEGMENT 
INCOMING_DIALOGUE_SEGMENT 
TRAN  SPORT_DATA_SEGMENT 
PIGGYBACKED_TRANSPORTJDATA_SEGMENT 
COUNT  ED_TRANSPORTJDATA_SEGMENT 
TRAN  SMITTED_PATAk_PACKET 
RETRAN  SMITTED JDATA^PACKET 

COMPOSITION: 


NOTES: 


SEE  ALIASES 

EXECUTE  DATA  PACKET  LAYER 


DATA  ELEMENT  NAME:  NSPSIZE 
ALIASES :  NONE 

VALUES  AND  MEANINGS: 

THE  MAXIMUM  TRANSPORT  PACKET  SEGMENT  SIZE  THIS  NODE  WILL 
ACCEPT.  THIS  NUMBER  MUST  BE  LESS  THAN  OR  EQUAL  TO  BLKSIZE 
NOTES:  ALL  TRANSPORT  LAYERS 


DATA  ELEMENT  NAME:  OBJTYPE 
ALIASES :  NONE 

VALUES  AND  MEANINGS: 

1.  GENERAL  TASK,  USER  PROCESS 

2.  FILE  ACCESS 

3.  UNIT  RECORD  SERVICES 

4.  APPLICATION  TERMINAL  SERVICES 

5.  COMMAND  TERMINAL  SERVICES 

6.  RSX-11M  TASK  CONTROL 

7 .  OPERATOR  SERVICES  INTERFACE 

8.  NODE  RESOURCE  MANAGER 

NOTES:  ALL  TRANSPORT  LAYERS 
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DATA  FLOW  DAME: 
ALIASES: 


COMPOSITION: 

NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


OLD  _ROUT ING_PACKETS 
ROUTING  _PACKET 
VALID_ROUTING_PACKET 
HOP  PED_ROUT ING_PACKE T 
INITIAL_ROUTE_PACEET 
ADJACENT JK)DEJROUTING_PACKET 

SEE  ALIASES 

EXECUTE  NETWORK  PROTOCOL  AT  PRIMARY  NODE  LAYER 


OPERATOR_PAS  SWO  RD_COMMAND 
NONE 

OPERATOR  COMMAND  PROVIDED  DURNING  THE  NODE  VERIFICATION 
PHASE  OF  INITIALIZATION. 

EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 
EXECUTE  INCOMING  DIALOGUE  MESSAGE  LAYER 
EXECUTE  DIALOGUE  SEGMENT  LAYER 
EXECUTE  STARTUP  PACKET  LAYER 


OPERATOR_START_COMMAND 

NONE 

OPERATOR  COMMAND  TO  START  INITIALIZATION  OF  THE  PHYSICAL 
LINK. 

EXECUTE  STARTUP  PACKET  LAYER 
EXECUTE  DIALOGUE  SEGMENT  LAYER 
EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 
EXECUTE  INCOMING  DIALOGUE  MESSAGE  LAYER 


OUTGOINGJ)IALOGUE_DATAwPACKET 

INCOMINGJ)IALOGUEJ»ACKET 

SEE  ALIASES 

EXECUTE  DATA  PACKET  LAYER 

EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 


DATA  FLOW  NAME 

ALIASES: 

COMPOSITION: 


OUTGOING_DIALOGUE_ME  S  SAGE 
SECONDARY_OUTGOINGJ)IALOGUE_MESSAGE 


OUTGO ING_DIALOGUE_MES SAGE  = 


NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 

DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 


|  TRANSIENT_ERROR_THRESHOLD_COUNTER_OVERFLOW 
I  FLOW_CONTROL__ERRORS 
I  OUTGOINGJDIALOGUE_DATA_PACKET 
I  RECEIVED_INCORRECT_PAS  SWORD_COMMAND 
I  ERROIUREASON 

EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 
OVERVIEW  LAYER 


OUTGOING_NODEJNETWORK_PACKET 
S  EC  0  NDARY_OUTGO I NG_NOD E_NE  TWO RK_PACKE T 

OUTGOING_NODE_NETWORK_PACKET  = 

T" AD JACENT_NODE_ROUT ING  JPACKET 
I  TRANSPORT_TO _NETWORK _PACKET 
I  OL  D_R0CT ING_PACKETS 
)  HOPPED_ROUTING_PACKET 
I  VALID  .NETWORK JPACKET 
I  INITIAL_ROUTE_PACKET 

EXECUTE  NETWORK  PROTOCOL  AT  PRIMARY  NODE  LAYER 
OVERVIEW  LAYER 


OUTGOING_NODE_TRANSPORTJPACKET 
NONADJACENT_RCXJTE_PACKET 
OUTGOING_TRANSPORT_ROUTE_PACKET 
SECONDARY^ OUTGOING_NODE_TRANSPORT_PACKET 
TRAN  SPORT  JPACKET 

SEE  ALIASES 

EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 
EXECUTE  NETWORK  PROTOCOL  AT  PRIMARY  NODE  LAYER 
OVERVIEW  LAYER 


OUTGOING_TRANSPORT_ROUTE_PACKET 

nonadjaceht_route_packet 

OUTGOING_NODE_TRANSPORT_PACKET 
SECONDARY_OUTGOING_NODE_TRANSPORT_PACKET 
TRAN SPORT  JPACKET 

SEE  ALIASES 

EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 


DECODE  ROOTS  HEADER  LATER 
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DATA  FLOW  NAME:  OUTGOING_SATELLITE_TRANSPORT_PACKET 

ALIASES :  SECONDARY_OCTGOING_SATELLITE_TRAN SPORT  _PACKET 

COMPOSITION: 

ODTGOING_SATELLITE_TRAN SPORT_PACKET  = 

I  NONADJACENT_SATELLITE_PACKET  I 
I  ADJACENT JNODEJPACRETS  I 

NOTES:  EXECUTE  OUTGOING  TRANSPORT  PACKETS  LAYER 

EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 
OVERVIEW  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


PASSWORD 

NONE 

THE  PASSWORD  FOR  THE  REQUESTING  NOBS,  IT  IS  THE  SAME  FOR 
THE  ENTIRE  NETWORK. 

ALL  TRANSPORT  LAYERS 


I 


DATA  ELEMENT  NAME:  PASSWRD 

ALIASES:  NONE 

VALUES  AND  MEANINGS: 

ACCESS  VERIFICATION  PASSWORD  =  AN  ARBITRARY  BYTE  STRING 
USED  FOR  CROSS-CHECK  VERIFICATION  (  NORMALLY  UNIQUELY 
PAIRED  WITH  THE  REQUESTOR- ID  OR  WITH  THE  SERVICE  ) . 
NOTES:  ALL  TRANSPORT  LAYERS 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


PERSISTENT_ERROR 

NONE 

REFER  TO  DATA  DICTIONARY  FOR  LINK  LEVEL  PROTOCOL. 
EXECUTE  CONNECT  PACKET  LAYER 


DATA  FLOW  NAME:  PIGGYBACKED JTRANSPORTJDATA-SEGMENT 

ALIASES:  INCOMINGJDIALOGUEJJATA 

NORMALJDATA-PACKET 

VALID_NORMAL_DATA_SEGMENT 

received_normal_data_segment 

INCOMING_DIALOGUE_SEGMENT 
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TEAM  SPORT_DATA_SEGMENT 
COUOTED_TRANSPORT_DATA_SEGMENT 

transmittedjiata_packet 
RETRANSMITTED J)ATiL?ACKET 

COMPOSITION: 

SEE  ALIASES 

NOTES:  EXECUTE  DIALOGUE  SEGMENT  LAYER 


DATA  FLOW  NAME:  PIGGYBACKED_TRANSPORT_INTERRDPT_PACKET 

ALIASES:  INCOMING_DIALOGUE_PACKET 

TRAN  SPORT__INTERHUPT_PACKET 
VALID_INTERRDPT_PACKET 

COMPOSITION: 


NOTES: 


SEE  ALIASES 

EXECUTE  I/L  PACKET  LAYER 


DATA  ELEMENT  NAME:  REASON 
ALIASES:  NONE 

VALUES  AND  MEANINGS: 

REFER  TO  FILE  BY  SAME  NAME. 
NOTES:  ALL  TRANSPORT  LAYERS 


DATA  FLOW  NAME:  RECEIVED JU>JACENT_NODE_PACKETS 

ALIASES:  VALID_SATELLITE_TRANSPORT_PACKET 

VALIDJMTADDR^PACKETS 
VAL  ID_DSTNODE__PACKETS 
VALID J)STNODE_CI_PACKET 

COMPOSITION: 

RECEIVED _>D  JACENT JNODEJPACKETS  = 

T" RECEIVED_TRANSPORT_INITIALIZATION_PACKET*7 
I  RECEIVED JTRANSPORTJDATAJPACKET  I 

I  RECEIVED_TRANSPORT_CONTROL_PACKET  I 

I  RECE IVED_TRAN SPORT_ACKNOWLEDGE_ PACKET  I 


NOTES:  DECODE  ROUTE  HEADER  LAYER 

EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


received_connect_confirhjpacket 

CONNECT_CON?IRM_PACKET 
SEE  ALIASES 

EXECUTE  CONNECT  PACKET  LAYER 
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DATA  FLOW  NAME 

ALIASES: 

COMPOSITION: 


RECE I  VED_CONNECT_INIT  IATE_PACKET 
C0NNECT_INITIATE_PAC5ET 


NOTES: 


SEE  ALIASES 

EXECUTE  CONNECT  PACKET  LATER 


DATA  ELEMENT  NAME:  RECEIVED_CORRECT_PAS SWORD_COMMAND 
ALIASES:  CORRECT_PAS SWORD  COMMAND  " 

VALUES  AND  MEANINGS: 

SEE  ALIASES 

NOTES:  EXECUTE  STARTUP  PACKET  LAYER 


DATA  FLOW  ”\ME: 
ALIASES: 

COMPOSITION: 

NOTES: 


RECEIVED_PISCONNECT_CONFIRM_PACKET 
FIR  ST  J)I  S  CONNECT_CONFIRM_PACKET 
DIS CONNECT_CONFIRM_PACKET 

SEE  ALIASES 

EXECUTE  CONTROL  PACKET  LAYER 
EXECUTE  CONNECT  PACKET  LAYER 
EXECUTE  DISCONNECT  PACKET  LAYER 


DATA  FLOW  NAME:  RECEIVED JDlSCONNECT_INITIATE_PACKET 

ALIASES:  DISCONNECT_INITIATE_?ACKET 

COMPOSITION: 


SEE  ALIASES 

NOTES:  EXECUTE  CONNECT  PACKET  LAYER 

EXECUTE  DISCONNECT  PACKET  LAYER 
EXECUTE  CONTROL  PACKET  LAYER 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


RECE IVED_I  / L_ACK_PACKE T 
NONE 


RECE  I  VED_I /L_ACK_PACKE  T  =  |  I/L_ACK_PACKET  I 

I  I  /L_NAK_ PACKET  I 

EXECUTE  ACKNOWLEDGE  PACKET  LAYER 


DATA  FLOW  NAME:  RECEIVED_I/LJPACKET 


f 
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ALIASES: 

COMPOSITION: 


VALID_I/L_PACKET 

RECEIVED_I/L_PACKET  =  T VALID_LINK_SERVICES_PACKEt"1 

I  VALID_INTERRDPT_PACKET  I 


NOTES:  EXECUTE  DATA  PACKET  LATER 


DATA  ELEMENT  NAME:  RECEIVED_INCORRECT_PAS SWORD_COMMAND 

ALIASES :  INCORRECT  JAS  SWORD_COMMAND 

VALUES  AND  MEANINGS: 

SEE  ALIASES 

NOTES:  EXECUTE  STARTUP  PACKET  LAYER 

EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 

NOTES: 


RECE IVED_INT ERCEPT_IN I T IAL IZ AT ION_PACKE T 
RECEIVED J(fODE_INITIALIZATION— PACKET 
RECEIVED_NO_INTERCEPT_INITIALIZATION_PACKET 
NODE_INITIALIZATION_VOJPACKET 
NODE_INIT IAL IZATION_V 1 JPACKET 

SEE  ALIASES 

EXECUTE  STARTUP  PACKET  LAYER 


! 


i 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 


NOTES: 


RECEIVED  JNODE_INITIALIZATION_PACKET 
RECEIVED_INTERCEPT— INITIAL IZATION_PACKET 
RECEIVED__NO_INTERCEPT_INITIALIZATION_PACKET 
NODE_INIT IALIZATION_VO_PACKET 
NODE_INITIALIZATION_Vl_?ACKET 

RECEIVED_NODE_INITIALIZATION_PACKET  =  MSGFLG  +  STARTTYPE 
+  NODEAD DR  +  NODENAME  +  FUNCTIONS  +  REQUESTS 
+  BLKSIZE  +  NSPSIZE  +  MAXLINKS  +  ROUTVER  + 
COMMVER  +  SYSVER 
EXECUTE  STARTUP  PACKET  LAYER 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


RECEIVED_NODE_VERIFICATION_PACKET 

NODE_VERIFICATION_PACKET 

RECEIVED_NODE_VERIFICATION_PACKET  *  MSGFLG  +  STARTTYPE  + 

PASSWORD 

EXECUTE  STARTUP  PACKET  LAYER 
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DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 

NOTES: 


RECEIVED JNO_INTERCEPT_INITIALIZATION_PACKET 
RECEIVED JK>DEJtNITIALIZATION_J»ACKET 
NODE_INITIALIZATION_VO_PACKET 
NODE_INITIALIZATION_Vl_PACKET 
RECEIVED_INTERCEPT_INITIALIZATIONJPACKET 

SEE  ALIASES 

EXECUTE  STARTUP  PACKET  LATER 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


RECEIVED_NORMAL_DATA_ACK  _PACKET 
NONE 

RECEIVED_NORMALJDATA_-ACK_PACKET  =  T~DATA^ACK_PACKEt”T 

I  DATAJJAKJPACKET  | 


NOTES: 


EXECUTE  ACKNOWLEDGE  PACKET  LAYER 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 


RECEIVED_NORMAL_DATA_SEGMENT 

INCOMING_DIALOGUEJ)ATA 

normal_data_packet 

VALID _NORMAL_DATA_SEGMENT 

INCOMING_DIALOGUE_SEGMENT 

TRAN  SPO  RT_DATA_SEGMENT 

PIGGYBACKED_TRANSPORTJ)ATA_SEGMENT 

COUNT  ED_TRANSPORT_jDATA_SEGMENT 

TRAN  SMITTED JDATAJPACKET 

RETRAN  SMITTED_PATA_PACKET 


NOTES: 


SEE  ALIASES 

EXECUTE  DATA  PACKET  LAYER 


DATA  ELEMENT  NAME:  RECEIVED _PACKET 

ALIASES:  NONE 

VALUES  AND  MEANINGS: 

REFER  TO  DATA  DICTIONARY  FOR  LINK  LEVEL  PROTOCOL. 
NOTES:  EXECUTE  OUTGOING  TRANSPORT  PACKETS  LAYER 


DATA  FLOW  NAME: 
ALIASES: 
COMPOSITION : 

NOTES: 


RECEIVED_TRAN SPORT _JACKNOWLEDGE_PACKET 
TRANSMITTED_TRANSPORT_ACKNOWLEDGEJPACKET 

SEE  ALIASES 

EXECUTE  ACKNOWLEDGE  PACKET  LAYER 


I 
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EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


RECE IVEDJTRAN  SPORT_CONTROL_PACKET 
TRAN  SMITTED_TRAN  SPORT_CONTRGL_PACKET 

SEE  ALIASES 

EXECUTE  CONNECT  PACKET  LAYER 
EXECUTE  CONTROL  PACKET  LAYER 

EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 


RECE IVEDJTRAN  SP 0  RT.DATA.PACKET 
NONE 

RECE IVEDJTRAN SPORT_DATAJPACKET  = 

T RECEIVED_NORMALJ)ATA_SEGMENT"7 
I  RECE  I  VED_I /L_PACKE  T  I 

EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 
EXECUTE  DATA  PACKET  LAYER 


RECEIVED JTRANSPORT_INITIALIZATION_PACKET 
NONE 

RECE IVEDJTRAN  SPORT JENITIAL IZ ATION JPACKET  = 

I  RECE  I V ED._IN C 0 RRECT  J?AS  SWORD_COMMAND  | 
I  RECEIVED_NODE_INITIALIZATION_PACKET  | 
I  RECEIVED_NODE_VERIFICATION_PACKET  | 
I  RECEIVED_CORRECT_PAS SWORD_COMMAND  I 

EXECUTE  STARTUP  PACKET  LAYER 

EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 


REJECT_CONFIRM 

NONE 

A  FLAG  USED  TO  INDICATE  THE  REJECTION  OF  A  RECEIVED. 
CONNECT_CONFIRM_PACKET.  RESULTS  IN  A 
DISCONNECT_INITIATE_PACKET  BEING  GENERATED. 

EXECUTE  CONNECT  PACKET  LAYER 


NOTES 


DATA  ELEMENT  NAME:  REJECT.CONNECT 
ALIASES:  NONE 

VALUES  AND  MEANINGS: 

A  FLAG  USED  TO  INDICATE  THE  REJECTION  OF  A  RECEIVED. 
CONNECT.INITIATEJPACKET.  RESULTS  IN  THE  GENERATION  OF  A 
DISCONNECT_INITIATE_PACKET. 

NOTES:  EXECUTE  CONNECT  PACKET  LAYER 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 

NOTES: 


RETRANSMITTED J5ATAJPACKET 

INCOMING_DIALOGUE_DATA 

NORMAL_DATA_PACKET 

VALID_NORMAL_J3ATA.SEGMENT 

RECEIVED_NORMALJ)ATA_SEGMENT 

INCOMING_DIALOGUE_SEGMENT 

TRANSPORT_DATA_SEGMENT 

PIGGYBACKED.TRANSPORT_^ATA_SEGMENT 

COUNT  ED_TRANSPORTJDATA_SEGMENT 

TRAN  SMITTED_PATA_?ACKET 

SEE  ALIASES 

EXECUTE  DIALOGUE  SEGMENT  LAYER 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 

NOTES: 


RETRANSMITTED_I/L_PACKET 
COUNT ED_TRANSPORT_I/L_PACKET 
TRANSPORT_I/L_PACKET 
TRANSMITTED_I/L_PACKET 

SEE  ALIASES 

EXECUTE  DIALOGUE  SEGMENT  LAYER 

EXECUTE  I/L  PACKET  LAYER 

EXECUTE  INCOMING  DIALOGUE  MESSAGE  LAYER 


DATA  ELEMENT  NAME:  RETURNING 
ALIASES:  NONE 

VALUES  AND  MEANINGS: 

THIS  BIT  IS  TURNED  ON  WHEN  A  PACKET  IS  ON  ITS  RETURN 
JOURNEY.  NOT  PRESENTLY  USED. 

NOTES:  ALL  NETWORK  LAYERS 


DATA  ELEMENT  NAME:  RETURNJRBQUEST 
ALIASES:  NONE 

VALUES  AND  MEANINGS: 
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NOTES s 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES: 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES : 

VALDES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 


THIS  BIT  INDICATES  THAT  AN  ONDELIVERABLE  PACKET  SHOOLD  BE 
RETORNED  TO  THE  SENDER. 

ALL  NETWORK  LAYERS 


REQDESTS 

NONE 


THE  REQDESTS  DESIRED  OF  THE  RECEIVER  BY  THE  SENDER  OF  THE 
INITIALIZATION  PACKET.  FORMAT: 

VERIF  =  NODE  VERIFICATION  PACKET 
REQDIRED. 

RINT  =  0  =  NO  INTERCEPT  =  SET 

ON  TRANSMIT  BY  A  ROOTING 
NODE  GOING  TO  A  SATELLITE 
NODE. 

=  1  =  INTERCEPT  =  SET  ON 
TRANSMIT  BY  A  ROOTING  NODE 
GOING  TO  A  ROOTING  NODE  OR 
ON  TRANSMIT  BY  A  SATELLITE 
NODE  GOING  TO  A  ROOTING 
NODE. 

ALL  TRANSPORT  LAYERS 


ROOTING_PACKET 

V  AL ID_ROOT ING_PACKE T 

HOPPED_ROOTING_PACKET 

INITIAL_ROOTE_PACKET 

ADA J ACENT_NODE_ROOT ING_PACKE T 

OLD_ROOTING_PACKETS 

ROOTING_PACKET  =  DESTINATION  +  LINF_COST  +  HOP_COONT 
EXECOTE  NETWORK  PROTOCOL  AT  PRIMARY  NODE  LAYER 


ROOTVER 

NONE 

THE  VERSION  OF  THE  ROOTING  ALGORITHM.  FORMAT: 

1 .  VERSION  NOMBER 

2 .  ECO  NOMBFP. 

3.  COSTOMER  LEVEL  NOMBER 

ALL  TRANSPORT  LAYERS 


RTHDR 
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ALIASES: 

VALUES  AMD  MEANINGS: 
FUNCTION 


NOTES : 


DATA  FLOW  NAME: 
ALIASES : 
COMPOSITION: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 

NOTES: 


NONE 

THE  RTHDR  IS  USED  BY  NODES  CONTAINING  AN  INTERCEPT 

TO  DETERMINE  THE  PHYSICAL  LINK  ON  WHICH  TO  SEND  THE 
PACKET  TOWARD  THE  DESTINATION  NODE.  A  TRANSPORT  PACKET 
GOING  TO  AN  ADJACENT  NODE  WILL  NOT  CONTAIN  THE  RTHDR 
FIELD  UNLESS  IT  IS  A  NETWORK_TO_NETWORK_PACKET.  FORMAT: 

1.  DSTN ODE  =  DESTINATION  NODE  NAME 

2.  SRC NODE  =  SOURCE  NODE  NAME 

3.  MPRI  =  PRIORITY 

ALL  TRANSPORT  LAYERS 


RTHDR_NONADJACENT_NODE_PACKETS 

NONE 

RTHDRJJONADJACENT_NODE_PACKETS  =  NONADJACENT_NODE_PACKETS 

+  RTHDR  FIELD 

EXECUTE  OUTGOING  TRANSPORT  PACKETS  LAYER 


RQSTRID 

NONE 


REQUESTOR  ID  *  A  CHARACTER-CODED  REFERENCE  THAT,  IN  A 

SINGLE  NODE  CONTEXT,  UNIQUELY  IDENTIFIES 
THE  PERSON  OR  PROCESS  REQUESTING  SERVICE. 
ALL  TRANSPORT  LAYERS 


SECONDARY_INCOMING_NODE_NETWOKK_JPACKET 

INCOMING_NODE_NETWORK_PACKET 

SEE  ALIASES 
OVERVIEW  LAYER 


SECONDARY_INCOMING_NODE_TRANSPORT_PACKET 
INCOMING_SATELLITE_TRAN SPORT_PACKET 
SECONDARY_INCOMING_SATELLITE_TRANSPORT_PACKET 
INCOMING_NODE_TRAN SPORT_PACKET 

SEE  ALIASES 
OVERVIEW  LAYER 
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DATA  FLOW  NAME: 
ALIASES : 


COMPOSITION: 

NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES : 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 

NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


SECOND ARY_INCOMING_SATELLITE_TRANSPORT_PACKET 
INCOMING_SATELLITE_TRANSPORT_PACKET 
INCOMING_NODE_TRAN  SPc  tC_PACKET 
SECONDARY_INCOMING_NODE_TRANSPORT_PACKET 

SEE  ALIASES 
OVERVIEW  LAYER 


SECONDARY_OOTGOING_DIALOGUE_MESSAGE 

ODTGOING_DlALOGDE_MESSAGE 

SEE  ALIASES 
OVERVIEW  LAYER 


SECOND ARY_OOTGOING_NODE_NETWORK_PACKET 
OUTGOING_NODE_NETWORK_?ACKET 

SEE  ALIASES 
OVERVIEW  LAYER 


SECOND ARY_ODTGOING_NODE_TRANSPORT_PACKET 
NONADJACENT _ROOTE_PACKET 
ODTGOING_TRANSPORT_RODTE_PACKET 
OUTGOING_NODE_TRANSPORT_PACKET 
TRAN  SPORT_PACKET 

SEE  ALIASES 
OVERVIEW  LAYER 


SECONDARY_OOTGOING_SATELLITE_TRANSPORT_PACKET 
OUTGO ING_SATELLITE_TRAN SPORT_PACKET 

SEE  ALIASES 
OVERVIEW  LAYER 


SEGMENT_COU  NT 
NONE 

THE  NUMBER  OF  SEGMENTS  THE  TRANSMITTER  IS  GOING  TO  BREAK 
THE  INCOMING  DIALOGUE  DATA  INTO. 
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NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


EXECUTE  DIALOGUE  SEGMENT  LATER 

EXECUTE  I/L  PACKET  LAYER 

EXECUTE  INCOMING  DIALOGUE  MESSAGE  LATER 


SEGNUM 

NONE 

THE  NUMBER  OF  THIS  SEGMENT,  MODULO  40%. 
ALL  TRANSPORT  LAYERS 


SEGNUMI 

NONE 

THE  NUMBER  OF  THIS  INTERRUPT  OR  LINK  SERVICE  PACKET. 
NUMBERS  FOR  INTERRUPT  OR  LINK  SERVICE  PACKETS  WILL  HAVE 
NO  RELATIONSHIP  TO  THE  NUMBERS  ASSIGNED  TO  NORMAL  DATA 
PACKETS.  EACH  PACKET  TYPE  UTILIZES  A  DIFFERENT 
SUBCHANNEL  ON  A  LOGICAL  LINK. 

ALL  TRANSPORT  LAYERS 


SEGSIZE 

NONE 

THE  MAXIMUM  SIZE  OF  A  NORMAL  DATA  SEGMENT  TO  BE  RECEIVED 
ON  THIS  LOGICAL  LINK. 

ALL  TRANSPORT  LAYERS 


SERVICES 

NONE 

REQUESTED  SERVICES.  FORMAT: 

FCOPT  =  FLOW  CONTROL  OPTION 
=  0  =  NONE 

=  1  =  SEGMENT  REQUEST  COUNT 

ALL  TRANSPORT  LAYERS 


SOURCE 

NONE 


THE  NAME  OF  THE  NODE  FROM  WHICH  THE  ROUTING  PACKET  CAME 
FROM, 


NOTES! 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES! 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 


ALL  NETWORK  LAYERS 


S&CADDR 

NONE 

THE  LOGICAL  LINK  SODRCE  ADDRESS.  THIS  ADDRESS  IS  ASSIGNED 
WHEN  A  LINK  IS  ESTABLISHED  ( CONNECT JPACKETS ) . 

ALL  TRANSPORT  LAYERS 


SRCNAME 

NONE 

THE  SODRCE  PROCESS  IDENTIFICATION.  DSE  OF  FORMAT  02  AS 
DESCRIBED  IN  DSTNAME. 

ALL  TRANSPORT  LAYERS 


START 

NONE 

A  FLAG  DSED  TO  INDICATE  THAT  THE  NODE  SHOULD  START  THE 
INITIALIZATION  PROCESS. 

EXECDTE  STARTDP  PACKET  LAYER 


STARTJJATA 

NONE 

A  FLAG  DSED  TO  TRIGGER  THE  RETRANSMITTING  OF  NEGATIVELY 
ACKNOWLEDGED  DATA  PACKETS. 

EXECDTE  DIALOGUE  SEGMENT  LAYER 


START_I/L 

NONE 

A  FLAG  DSED  TO  TRIGGER  THE  RETRANSMITTING  OF  NEGATIVELY 
ACKNOWLEDGED  INTERRUPT  AND  LINK  SERVICES  PACKETS. 
EXECDTE  I/L  PACKET  LAYER 


STARTTYPE 

NONE 
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VALUES  AND  MEANINGS: 


NOTES: 


TYPE  OF  STARTUP  MESSAGE. 
ALL  TRANSPORT  LAYERS 


1  =  NODE_INITIALIZATIONJPACKET 

2  =  NODE_VERIFICATION_PACKET 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


STOP 

NONE 

A  FLAG  USED  TO  START  LOGICAL  LINK  DISCONNECTION  DUE  TO  A 
RECEIVED  J)ISCONNECT_REQUEST_COMMAND. 

EXECUTE  CONNECT  PACKET  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


STOP_LINK 

NONE 

REFER  TO  DATA  DICTIONARY  FOR  LINK  LEVEL  PROTOCOL. 
EXECUTE  DISCONNECT  PACKET  LAYER 


DATA  ELEMENT  NAME:  STOP_LINK_NOW 
ALIASES:  NONE 

VALUES  AND  MEANINGS: 

A  FLAG  USED  TO  INDICATE  THAT  A  DISCONNECT_CONFIRMJ?ACKET 
CAN  NON  BE  ISSUED  SINCE  ALL  DATJL.PACKETS  SENT  OUT  HAVE 
BEEN  POSITIVELY  ACKNOWLEDGED. 

NOTES:  EXECUTE  DISCONNECT  PACKET  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


SYSVER 

NONE 

A  STRING  DESCRIBING  THE  OPERATING  SYSTEM,  DATA  OF 
CREATION,  ETC. 

ALL  TRANSPORT  LAYERS 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


TRANSIENT_ERRORjrHRESHOLD_COUNTER_OVERFLOW 

NONE 

REFER  TO  DATA  DICTIONARY  FOR  LINK  LEVEL  PROTOCOL. 
EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 


J 
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DATA  ELEMENT  NAME:  TRANSMITJPACKET 
ALIASES:  NONE 

VALUES  AND  MEANINGS: 

REFER  TO  DATA  DICTIONARY  FOR  LINK  LEVEL  PROTOCOL. 
NOTES:  EXECUTE  OUTGOING  TRANSPORT  PACKETS  LAYER 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 

NOTES: 


TRAN  SMITTED_DATA_PACKET 
INCOMING_DIALOGUE_PACKET 
NORMAL  JIATAJACKET 
VALID_NORMAL_DATA_ SEGMENT 
RECE IVED_NORMAL_DATA_SEGMENT 
INCOMING_DIALOGUE_SEGMENT 
TRAN SPORT  J)ATA_SEGMENT 
PIGGYBACKED_TRAN SPORT JDATA^SEGMENT 
COUNT  ED_TRAN  SPO  RT_DA  TA_S  EGMENT 
RETRAN  SMITTED  JQATAJACKET 

SEE  ALIASES 

EXECUTE  DIALOGUE  SEGMENT  LAYER 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 

NOTES: 


TRANSMITTED_I/L_PACKET 
COUNT ED_TRANSPORT_I/L_PACKET 
TRANSPORT_I/L_PACKET 
RETRANSMITTED_I/L_PACKET 

SEE  ALIASES 

EXECUTE  DIALOGUE  SEGMENT  LAYER 

EXECUTE  I/L  PACKET  LAYER 

EXECUTE  INCOMING  DIALOGUE  MESSAGE  LAYER 


DATA  FLOW  NAME:  TRAN SMITTED_TRAN SPORT _ACKNOWLEDGE_PACKE T 

ALIASES :  RECEIVED_TRANSPORT_ACKNOWLEDGE_PACKET 

COMPOSITION: 

TRAN  SMITTED_TRAN  SPO  RT_ACKNOWLEDGE JPACKET  = 

T dataj^ck_packet"7 

I  DATAJNAK_PACKET  I 
i  I/LJVCK_PACKET  | 
I  I/L_NAK_PACKET  I 


NOTES:  EXECUTE  DATA  PACKET  LAYER 

EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 
EXECUTE  OUTGOING  TRANSPORT  PACKETS  LAYER 


<*  * 


4  « 
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DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


TRAN  SMITTED_TRAN  SPORT_DATA^_PACKET 
NONE 


TRANSMITTED_TRANSPORTJJATAbJACKET  = 

F RETRANSMITTED JDATA_PACKET~ 
I  RETRANSMITTED_I/LJPACKET  | 
I  TRANSMITTED_I/L_PACKET  | 
I  TRAN  SHITTED  JDATA_PACKET  | 

EXECUTE  DIALOGUE  SEGMENT  LAYER 
EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 
EXECUTE  OUTGOING  TRANSPORT  PACKETS  LAYER 
EXECUTE  INCOMING  DIALOGUE  MESSAGE  LAYER 


TRANSMITTED_TRANSPORT_CONTROL_?ACKET 

RECIEVED_TRANSPORT_CONTROL_PACKET 

TRANSMITTED_TRANSPORT_CONTRQL_PACKET  * 

T” disconnect_initiate_packet"7 

I  CONNECT_INITIATE_PACKET  | 
I  CONNECT_CONFIRM_PACKET  | 
I  DISCONNECT_CONFIRM_PACKET  | 

EXECUTE  CONNECT  PACKET  LAYER 
EXECUTE  CONTROL  PACKET  LAYER 

EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 
EXECUTE  OUTGOING  TRANSPORT  PACKETS  LAYER 


TRANSMITTED_TRANS?ORT_INITIALIZATION_PACKET 

NONE 

TRANSMITTED_TSANSPORT_INITIALIZATION JACKET  > 

T NODE_INIT IAL IZATIOH_YO_PACKIT”T 
I  NODE_INITIALIZATION_VI_PACKET  | 

I  NODE_VERIFICATION JPACKIT  | 

I  CORRECT _PAS  SWORD_COMMAND  I 

I  INCORRECT_PAS 8W0RD_C0KMAND  I 

EXECUTE  STARTUP  PACKET  LAYER 

EXECUTE  OUTGOING  TRANSPORT  PACKETS  LAYER 

EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODI  LAYER 
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DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 


NOTES: 


TRANSPORT_DATAk_SEGMENT 

INCOM ING_DI ALOGUE_DATA 

NORMAL _DATAU_PACKET 

VALID _NORMAL_DATA_SEGMENT 

RECEIVED  JJORMALJ1ATAJ3EGMENT 

INCOMING_DIALOGUE_SEGMENT 

PIGGYBACKED_TRANSPORT_DATA_SEGMENT 

CODNTED_TRANSPORT_DATA_SEGMENT 

RETRANSMITTED_DATA_PACKET 

SEE  ALIASES 

EXECUTE  DIALOGUE  SEGMENT  LATER 


DATA  FLOW  NAME:  TRANSPORT_INTERRDPT_PACKET 

ALIASES:  INCOMING_DIALOGUE_INTERKDPT 

P IGGYBACKED_TRAN SPO  RT_INT  ERRDPT_PACKE  T 
VALID_INTERRDPT_PACKET 

COMPOSITION: 


NOTES: 


SEE  ALIASES 

EXECUTE  I/L  PACKET  LAYER 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 

NOTES: 


TRANSPORTJPACKET 
NONADJACENTJROUTEJPACKET 
OUTGOING__TRANSPORT_ROUTE_PACKET 
OUTGOING_NODE_TRAN SPORT_PACKET 
SECONDARY_OUTGOING_NODE_TRANSPORT_ PACKET 

SEE  ALIASES 

EXECUTE  NETWORK  PROTOCOL  AT  PRIMARY  NODE  LAYER 


DATA  FLOW  NAME:  TRANSPORT_TO_NETWORK_PACKET 

ALIASES:  NONE 

COMPOSITION: 

TRAN  SPORT_TO__NETWORK  JPACKET  *  TRANSPORTJPACKET  ♦  HOPS  ♦ 

SOURCE  ♦  DESTINATION  + 
CHOKE  +  RETURN  ♦  REQUEST  + 
RETURNING  +  VERSION 

NOTES:  EXECUTE  NETWORK  PROTOCOL  AT  PRIMARY  NODE  LAYER 


r 


DATA  ELEMENT  NAME:  TSTDATA 
ALIASES:  NONE 

VALUES  AND  MEANINGS: 
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ROTES 


ANY  TEST  DATA  PATTERN.  THIS  PACKET  IS  IGNORED  ON  RECEIVE 
ALL  TRANSPORT  LAYERS 


■ 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 

NOTES: 


VALID_DSTADDR_PACKETS 
RECEIVED _^ADJACENT_NODE_PACKETS 
VALID_SATELLITS_TRAN  SPORT_PACKETS 
VAL ID_DSTNODE_PACKE TS 
VALID J)STNODE_CI_PACKET 

SEE  ALIASES 

DECODE  ROUTE  HEADER  LAYER 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 

NOTES: 


VALID  JDSTNODE_CI_?ACKET 
RECEIVED_ADJACENT_NODE_PACKETS 
VALID_SATELLITE_TRANSPORT^ PACKET 
VALID _DSTADDR_PACKETS 
VALID  J)STNODE_PACKETS 

SEE  ALIASES 

EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 

DECODE  ROUTE  HEADER  LAYER 

EXECUTE  OUTGOING  TRANSPORT  PACKETS  LAYER 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 

NOTES: 


VALID_PSTN0DE_PACKETS 

RECE IVED_AD JACENT_NODE_PACKETS 

VALID_SATELLITE_TRANSPORT_PACKET 

VALIDJDSTADDRJPACKETS 

VALID J)STNODE_CI_PACKETS 

SEE  ALIASES 

DECODE  ROUTE  HEADER  LAYER 


DATA  FLOW  NAME:  VALID_I/L_PACKET 

ALIASES:  RECEIVED_I/L_PACKET 

COMPOSITION: 

SEE  ALIASES 

NOTES:  EXECUTE  DATA  PACKET  LAYER 


DATA  FLOW  NAME:  VALID_INTERRUPT_PACKET 

ALIASES:  INCOMING  _DIALOGUE_INTERRDPT 

TRANSPORT_INTERHUPT_PACKET 


i 


i 
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COMPOSITION: 

NOTES: 

DATA  FLOU  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 

DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 

DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 

DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 

NOTES: 


PIGGYBACKED_TRAN  SPORT_INTERRDPT_PACKET 
SEE  ALIASES 

EXECUTE  DATA  PACKET  LATER 


valid_linr_sekvices_packet 

INTERRDPT_LINK_SERVICES_PACKET 

DATAk-LINK_SERVICES_PACKET 

SEE  ALIASES 

EXECUTE  DATA  PACKET  LAYER 


VALID_NETWORK_PACKET 

NETWORK_TO_NETWORK_PACKET 

VALID_NETWORK_TO_NETWORK_PACKET 

SEE  ALIASES 

EXECUTE  NETWORK  PROTOCOL  AT  PRIMARY  NODE  LAYER 


VALID_NETWORK_TO_NETWORK_PACKET 

NETWORK_TO_NETWORK_PACKET 

VALID_NETWORKJPACKET 

SEE  ALIASES 

EXECUTE  NETWORK  PROTOCOL  AT  PRIMARY  NODE  LAYER 


VALID_NORMAL_DATA_SEGMENT 

INCOMINGJDIALOGUEJPACKET 

NORMAL  JDATAJACKET 

RECEIVED_NORMALJDATA_SEGMENT 

INCOMING_DIALOGUE_SEGMENT 

TRAN  SPORT  JDATA_SEGMENT 

PIGGYBACKED_TRAN  SPORT  JDATAWSEGMENT 

COUNT ED_TRANSPORT_PATA_SEGMENT 

TRAN  SMITTED  J3ATA_PACKET 

RETRANSMITTEDJJATA^PACKET 

SEE  ALIASES 

EXECUTE  DATA  PACKET  LAYER 
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A  A 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 

NOTES: 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 

NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AMD  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


VAL ID_R0UT IN G_PACKE T 
ROUTING_PACKET 
HOPPED _ROUTING_PACKET 
INITIAL JROUTE_PACKET 
ADJACENT_NODE_EOUTING_PACKET 
OLD_ROUT  ING_PACKETS 

SEE  ALIASES 

EXECUTE  NETWORK  PROTOCOL  AT  PRIMARY  NODE  LAYER 


VALID_SATELLITE_TRANSPORT_PACKET 
RECEIVED JU)JACENT_NODE_PACKETS 
VALIDJDSTADDR_PACKETS 
VALID_DSTNODE_PACKETS 
VALID_DSTNODE_CI_PACKET 

SEE  ALIASES 

DECODE  ROUTE  HEADER  LAYER 


VERIFY_CLEAR 

NONE 

A  FLAG  TO  INDICATE  THAT  A 
RECEIVED_INTERCEPT_INITIALIZATION_PACKET 
WAS  RECEIVED  WITH  THE  VERIFY  BIT  NOT  SET  CAUSING 
GENERATION  OF  ANOTHER  RECE I VED_INTERCEPT_INI T IAL IZ AT ION_ 
PACKET  WITH  THE  VERIFY  BIT  NOT  SET. 

EXECUTE  STARTUP  PACKET  LAYER 


VERIFY^SET 

NONE 

A  FLAG  USED  TO  INDICATE  THAT  A  RECEIVED_INTERCEPT_ 

INIT IAL IZ AT10N_PACKET  WAS  RECEIVED  WITH  THE  VERIFY  BIT 
SET  CAUSING  THE  GENERATION  OF  A  NODE_VERIFICATION_PACKET. 
EXECUTE  STARTUP  PACKET  LAYER 


VERSION 

NONE 

THIS  BIT  TELLS  WHICH  VERSION  OF  THE  NETWORK  PROTOCOL 
GENERATED  THE  PACKET.  PRESENTLY  NOT  USED. 

ALL  NETWORK  LAYERS 
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FILE  OR  DATABASE 

ALIASES: 

COMPOSITION: 


ORGANIZATION: 

NOTES: 


FILE  OR  DATABASE 

ALIASES: 

COMPOSITION: 


ORGANIZATION: 

NOTES: 


FILE  OR  DATABASE 

ALIASES: 

COMPOSITION: 


ORGANIZATION: 

NOTES: 


FILE  DEFINITIONS  t  T/N) 


NAME:  ACK_D_FILE 
NONE 

ACKJ)_FILE  =  THE  SEGMENT  NUMBER  OF  THE  LAST  DATA 
PACKET  POSITIVELY  ACKNOWLEDGED. 

1  8-BIT  BYTE 

EXECUTE  CONTROL  PACKET  LAYER 

EXECUTE  CONNECT  PACKET  LAYER 

EXECUTE  DISCONNECT  PACKET  LAYER 

EXECUTE  DIALOGUE  SEGMENT  LAYER 

EXECUTE  INCOMING  DIALOGUE  MESSAGE  LAYER 

EXECUTE  DATA  PACKET  LAYER 

EXECUTE  ACKNOWLEDGE  PACKET  LAYER 


NAME:  ACK_I/L_FILE 
NONE 

ACK_I/L_FILE  =  THE  SEGMENT  NUMBER  OF  THE  LAST 
INTERRUPT  OR  LINK  SERVICES  PACKET  POSITIVELY 
ACKNOWLEDGED  TO  THIS  NODE. 

1  8-BIT  BYTE 

EXECUTE  I/L  PACKET  LAYER 
EXECUTE  INCOMING  DIALOGUE  MESSAGE  LAYER 
EXECUTE  DATA  PACKET  LAYER 
EXECUTE  ACKNOWLEDGE  PACKET  LAYER 


NAME:  AD J AC ENT_NODE_PARA METERS 
NONE 

ADJACENT_NODE_PARA METERS  =  NODEADDR  +  NODENAME  +  NO 

INTERCEPT  ♦  INTERCEPT 
REQUESTED  +  BLKSIZE  + 
NSPSIZE  +  MAXLNKS  +  COMMVER 
+  SYSVER  +  CORRECT. 
PASSWORD  +  LINK_ACCES SABLE 
VARIABLE  LENGTH  8- BIT  BYTE  COMBINATIONS 
EXECUTE  STARTUP  PACKET  LAYER 
EXECUTE  CONTROL  PACKET  LAYER 
EXECUTE  CONNECT  PACKET  LAYER 
EXECUTE  DIALOGUE  SEGMENT  LAYER 
EXECUTE  INCOMING  DIALOGUE  MESSAGE  LAYER 
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FILE  OR  DATABASE 

ALIASES: 

COMPOSITION: 


ORGANIZATION: 
NOTES : 


FILE  OR  DATABASE 

ALIASES: 

COMPOSITION: 


ORGANIZATION: 
NOTES : 


FILE  OR  DATABASE 

ALIASES: 

COMPOSITION: 


ORGANIZATION: 

NOTES: 


NAME :  DATAJteMORY 
NONE 

DATA^MEMORY  =  DATA  SEGMENTS  ARE  LOADED  INTO  MEMORY 
UNTIL  SUCH  TIME  A  POSITIVE 
ACKNOWLEDGEMENT  IS  RECEIVED. 

ARRAY  OF  VARIABLE  BYTE  LENGTH  WORDS. 

EXECUTE  DIALOGUE  SEGMENT  LAYER 


NAME :  DATA_NAK_JILE 
NONE 

DATA_NAK_FILE  =  THE  SEGMENT  NUMBER  OF  THE  LAST  DATA 

PACKET  NEGATIVELY  ACKNOWLEDGED  TO  THIS 
NODE,  AT  OTHER  TIMES  IT  IS  EQUAL  TO 
TRAN  SMIT_D_FILE  +  1. 

1  8-BIT  BYTE 

EXECUTE  DIALOGUE  SEGMENT  LAYER 
EXECUTE  DATA  PACKET  LAYER 
EXECUTE  ACKNOWLEDGE  PACKET  LAYER 


NAME:  DIALOGUE_PROCESS_TABLE 
NONE 

DIALOGUE_PROCESS_TABLE  =  DESTINATION  NODE  NAME  + 

DESTINATION  PROCESS 
IDENTIFICATION  +  SOURCE 
PROCESS  IDENTIFICATION  + 
LINK  IDENTIFIER  +  ACCESS 
CONTROL  INFORMATION  + 
SOURCE  NODE  NAME  +  SOURCE 
PROCESS  IDENTIFICATION  + 
DESTINATION  PROCESS 
IDENTIFICATION  + 

REPLY  IDENTIFIER  +  REMOTE 
PROCESS'S  SEGMENT  SIZE. 
VARIABLE  LENGTH  8- BIT  BYTE  WORDS. 

EXECUTE  CONNECT  PACKET  LAYER 

EXECUTE  DISCONNECT  PACKET  LAYER 

EXECUTE  DIALOGUE  SEGMENT  LAYER 

DECODE  ROUTE  HEADER  LAYER 

EXECUTE  DATA  PACKET  LAYER 

EXECUTE  I/L  PACKET  LAYER 

EXECUTE  OUTGOING  TRANSPORT  PACKETS  LAYER 
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FILE  OR  DATABASE  NAME:  FLOW_CONTROL_PARA METERS 

ALIASES:  NONE 

COMPOSITION: 

FLOW_CONTROL_PARA METERS  =  DATA  FLOW  CONTROL  SWITCH  + 

INTERRUPT  REQUEST  COUNT  + 
DATA  REQUEST  SWITCH  +  DATA 
REQUEST  COUNT 

ORGANIZATION:  INITIAL  PARAMETERS  =  OPEN, 1 .SEGMENT, 0  RESPECTIVELY 

NOTES:  EXECUTE  DIALOGUE  SEGMENT  LAYER 

EXECUTE  INCOMING  DIALOGUE  MESSAGE  LAYER 
EXECUTE  I/L  PACKET  LAYER 
EXECUTE  DATA  PACKET  LAYER 
EXECUTE  CONTROL  PACKET  LAYER 
EXECUTE  CONNECT  PACKET  LAYER 


FILE  OR  DATABASE  NAME:  I/L_MEMORY 
ALIASES :  NONE 

COMPOSITION: 

I/L_MEMORY  =  INTERRUPT  AND  LINK  SERVICE  PACKETS  ARE 
LOADED  INTO  MEMORY  UNTIL  SUCH  TIME  A 
POSITIVE  ACKNOWLEDGEMENT  IS  RECEIVED. 
ORGANIZATION:  ARRAY  OF  VARIABLE  BYTE  LENGTH  WORDS. 

NOTES:  EXECUTE  I/L  PACKET  LAYER 


FILE  OR  DATABASE  NAME:  I/L_NAK_FILE 
ALIASES :  NONE 

COMPOSITION: 

I/L_NAK_FILE  =  THE  SEGMENT  NUMBER  OF  THE  LAST 
INTERRUPT  OR  LINK  SERVICES  PACKET  NEGATIVELY 
ACKNOWLEDGED  TO 

THIS  NODE.  ALSO  EQUAL  TO  TRAN SMIT_I/L_FILE  +  1. 
ORGANIZATION:  1  8- BIT  BYTE 

NOTES:  EXECUTE  I/L  PACKET  LAYER 

EXECUTE  DATA  PACKET  LAYER 
EXECUTE  ACKNOWLEDGE  PACKET  LAYER 


FILE  OR  DATABASE  NAME:  INITIAL_PARAMETER_LIST 

ALIASES :  NONE 

COMPOSITION: 

INITIAL_PARAMETER_LIST  =  NODEAD DR  +  NODENAME  + 

T” no.interceptT  +  M N0_INTERCEPT_REQUESTED~7 
I  INTERCEPT  I  I  INTERCEPT_REQUESTED  | 


ORGANIZATIONS 

NOTES: 


FILE  OR  DATABASE 
ALIASES : 
COMPOSITION: 

ORGANIZATION: 
NOTES : 


FILE  OR  DATABASE 

ALIASES: 

COMPOSITION: 

ORGANIZATION: 
NOTES : 


FILE  OR  DATABASE 

ALIASES: 

COMPOSITION: 


+  BLKSIZE  +  NSPSIZE  +  MAXLNKS  +  RODTVER  + 
COMMVER  +  SYSVER 

VARIABLE  LENGTH  8-BIT  BYTE  COMBINATIONS 
EXECUTE  STARTUP  PACKET  LAYER 


NAME :  LINK_TO_TRAN SPORT_COMMAND_TABLE 
NONE 

REFER  TO  DATA  DICTIONARY  FOR  LINK  LEVEL  PROTOCOL 

SINGLE  VARIABLE 

EXECUTE  STARTUP  PACKET  LAYER 

EXECUTE  CONNECT  PACKET  LAYER 

EXECUTE  TRANSPORT  PROTOCOL  AT  PRIMARY  NODE  LAYER 


NAME:  LS_FILE 
NONE 

LS_FILE  =  SEGMENT  NUMBER  OF  LAST  PACKET  SENT. 
1  BYTE 

EXECUTE  DIALOGUE  SEGMENT  LAYER 
EXECUTE  INCOMING  DIALOGUE  MESSAGE  LAYER 
EXECUTE  CONTROL  PACKET  LAYER 
EXECUTE  CONNECT  PACKET  LAYER 
EXECUTE  DISCONNECT  PACKET  LAYER 


NAME:  REASON 
NONE 

A  FILE  WITH  THE  FOLLOWING  ERRORS: 
ERROR  CODE  MEANING 


0  NO  ERROR 

1  RESOURCES  ALLOCATION  FAILURE 

2  DESTINATION  NODE  DOES  NOT  EXIST 

3  NODE  SHUTTING  DOWN 

4  DESTINATION  PROCESS  DOES  NOT  EXIST 

5  INVALID  PROCESS  NAME  FIELD 

6  DESTINATION  PROCESS  QUEUE  OVERFLOW 

7  UNSPECIFIED  ERROR  CONDITION 

8  THIRD  PARTY  ABORTED  THE  LOGICAL  LINK 

9  LINK  ABORT  BY  DIALOGUE  PROCESS 

10  FLOW  CONTROL  VIOLATION- ILLEGAL  FCVAL  IN  LINK 

SERVICES  MESSAGE 

11  TOO  MANY  CONNECTIONS  TO  NODE 
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ORGANIZATION: 
NOTES : 


FILE  OR  DATABASE 

ALIASES: 

COMPOSITION: 


ORGANIZATION: 

NOTES: 


FILE  OR  DATABASE 

ALIASES: 

COMPOSITION: 


ORGANIZATION: 

NOTES: 


FILE  OR  DATABASE 

ALIASES: 

COMPOSITION: 


12  TOO  MANY  CONNECTIONS  TO  DESTINATION  PROCESS 

13  ACCESS  NOT  PERMITTED-UNACCEPTABLE  RQSTRID  OR 

PASSWORD 

14  LOGICAL  LINK  SERVICES  MISMATCH 

15  UNACCEPTABLE  ACCOUNT  INFORMATION-UNAUTHORIZED 

OR  ACCOUNT  BALANCE  UNACCEPTABLE 

16  SEGSIZE  TOO  SMALL 

17  DIALOGUE  PROCESS  ABORTED,  TIMED  OUT,  OR 

CANCELLED  REQUEST 

18  NO  PATH  TO  DESTINATION  NODE 

19  FLOW  CONTROL  FAILURE 

20  DSTADDR  LOGICAL  LINK  DOES  NOT  EXIST 

21  CONFIRMATION  OF  DISCONNECT  INITIATE 

22  IMAGE  DATA  FIELD  TOO  LONG- RQSTRID,  PASSWORD, 

ACCOUNT,  USRDATA,  AND  DATA. 

EACH  ERROR  =  2  BYTES 
DECODE  ROUTE  HEADER  LAYER 
EXECUTE  CONTROL  PACKET  LAYER 
EXECUTE  CONNECT  PACKET  LAYER 
EXECUTE  DISCONNECT  PACKET  LAYER 


NAME :  RECEIVED_D_FILE 
NONE 

REC E I VED_J)_FILE  =  MOST  CURRENT  DATA  SEGMENT  NUMBER 
RECEIVED. 

i  8-BIT  BYTE 

EXECUTE  DATA  PACKET  LAYER 


NAME:  RECEIVED_I/L_FILE 
NONE 

RECEIVED_I/L_FILE  =  MOST  CURRENT  I/L  SEGMENT  NUMBER 

RECEIVED. 

1  8- BIT  BYTE 

EXECUTE  DATA  PACKET  LAYER 


NAME :  ROUT ING_TABLE_1 
NONE 

ROUT ING_TABLE_1  =1-2=6 

2- 3  =  5 

3- 1  =  10 

1- 2-3  =  11 

2- 3-1  =  15 
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ORGANIZATION: 


NOTES: 


FILE  OR  DATABASE 

ALIASES: 

COMPOSITION: 


ORGANIZATION: 


NOTES : 


FILE  OR  DATABASE 

ALIASES: 

COMPOSITION: 


ORGANIZATION: 

NOTES: 


FILE  OR  DATABASE 

ALIASES: 

COMPOSITION: 


ORGANZATION: 
NOTES : 


FILE  OR  DATABASE 

ALIASES: 

COMPOSITION: 


3-1-2  =  16 

ABOVE  NUMBERS  HAVE  ASSOCIATED  NODE  NAMES. 

THIS  IS  A  TABLE  THAT  CONTAINS  THE  PERMXKATE  LINK  COST. 
IF  THE  FULL  NETWORK  WERE  UP  AND  RUNNING.  THE  ABOVE 
VALUES  ARE  FOR  A  3  ROUTING  NODE  NETWORK  CONFIGURATION. 
EXECUTE  NETWORK  PROTOCOL  AT  PRIMARY  NODE  LAYER 


NAME :  ROUT ING_TABLE_2 
NONE 

ROUT ING_TABLE_2  =  1-2  +  2-3  +  3-1  +  1-2-3  ♦  2-3-1  + 
3-1-2 

THIS  IS  THE  TABLE  THAT  IS  ACTUALLY  USED  AS  THE  NETWORK 
ROUTING  TABLE  FOR  GENERATING  AND  SENDING  ROUTING 
PACKETS . 

EXECUTE  NETWORK  PROTOCOL  AT  PRIMARY  NODE  LAYER 


NAME:  SATELLITE_NODE_PARAMETERS 
NONE 

SATELLITE_NODE_PARAMETERS  =  NODEAD DR  +  NODENAME  + 

INTERCEPT  +  NO  INTERCEPT  + 
BLKSIZE  +  NSPSIZE  + 

MAXLNKS  +  ROUTVER  + 
COMMVER  +  SYSVER  + 

PASSWORD 

VARIABLE  LENGHT  8-BIT  BYTE  COMBINATIONS 
EXECUTE  STARTUP  PACKET  LAYER 
DECODE  ROUTE  HEADER  LAYER 


NAME:  TRANSMIT_D_FILE 
NONE 

TRANSMIT_D_FILE  =  DATA  TRANSMITTING  SEGMENT  NUMBER, 
MODULO  40%. 

1  8- BIT  BYTE 

EXECUTE  DIALOGUE  SEGMENT  LAYER 


NAME :  TRANSMIT_I/L_FILE 
NONE 

TRANSMIT_I/L_FILE  =  INTERRUPT  OR  LINK  SERVICES 

TRANSMITTING  SEGMENT  NUMBER, 
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ORGANIZATION: 

NOTES: 


FILE  OR  DATABASE 

ALIASES: 

COMPOSITION: 

ORGANIZATION: 

NOTES: 


MODULO  4096. 

1  8-BIT  BYTE 

EXECUTE  I/L  PACKET  LAYER 


NAME:  TRAN SPORT_TO_LINK_COMMAND_T ABLE 
NONE 

REFER  TO  DATA  DICTIONARY  FOR  LINK  LEVEL  PROTOCOL. 
SINGLE  VARIABLE 

EXECUTE  DIALOGUE  SEGMENT  LAYER 

EXECUTE  STARTUP  PACKET  LAYER 

EXECUTE  DISCONNECT  PACKET  LAYER 

EXECUTE  OUTGOING  TRANSPORT  PACKETS  LAYER 

EXECUTE  NETWORK  PROTOCOL  AT  PRIMARY  NODE  LAYER 
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PROCESS  NAME:  DECODE  RTHDR  FIELD 

PROCESS  NDMBER:  1.1.1 

PROCESS  DESCRIPTION: 

WHEN  Input  =  INCOMING_SATELLITE_TRANSPORT_PACKET  or  INCOMING  _NODE_TRAN SPORT 
PACKET  then 

Check  £or  RTHDR  field 

IF  RTHDR  field  not  present  then 

Output  RECEIVED_ADJACENTJNODE_PACKETS 

ELSE 

IF  DSTNODE  =  velid  satellite  node  and  MSGFLG  =  00011000 
then 

Output  VALID_DST_CI_PACKET 
ELSEIF  DSTNODE  =  valid  satellite  node  then 
Output  VAL ID_DSTNODE_PACKETS 
ELSEIF  DSTNODE  =  valid  routing  node  then 

Output  OCTGOING_TRAN SPORT  _ROOTE  JPACKET 
ELSE  output  INVALID_DSTNODE_PACKETS 


PROCESS  NAME:  DECODE  MSGFLG  FIELD 

PROCESS  NDMBER:  1.1.2 

PROCESS  DESCRIPTION: 

IF  MSGFLG  field  *  valid  destination  logical  link  address  then 
Output  VALIDJDSTADDRJACKETS 
ELSE  output  INVALID JDSTADDR_PACKETS 


PROCESS  NAME:  GENERATE  FIRST  DISCONNECT  CONFIRM 

PROCESS  NDMBER:  1.1.3 

PROCESS  DESCRIPTION: 

IF  Input  =  INVALID  J)STADDR_PACKETS  or  DISCONHECT_REQOIRED  or  INVALIDJJSTNODE 
PACKETS  then 

Extract  REAS 0N_C0DE  from  REASON  file  and 
Output  FIRST_DISCONNECT_CONFIRMJPACKET 
ELSE  Null 


PR0CES8  NAME:  EXAMINE  LOGICAL  LINK  DATABASE 

PROCESS  NDMBER:  1.1.4 

PROCESS  DESCRIPTION: 

IF  SATELLITR_NODE_PARAMETERS  are  null  then 
Output  DISCONNECT _REQDIRED 
ELSE  output  VALID_SATZLLITE_TRANSPORT_PACKET 
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PROCESS  NAME:  PASS  TO  SATELLITE 

PROCESS  NUMBER:  1.1.5 

PROCESS  DESCRIPTION: 

WHEN  Input  if  VAL ID_SATEL LI TR_TRAN SPO RT_PACKE T  or  VALID _DSTNODE_CI_PACKET 
Pm  to  aatellite  node  according  to  DSTADDR  value. 

ELSE  Null 


PROCESS  NAME:  DECODE  PACKET  TYPE 

PROCESS  NUMBER:  1.2 

PROCESS  DESCRIPTION: 

WHEN  Input  if  RECEIVEDJU>JACENT_NODE_PACKETS  then 

IF  MSGFLG  =  0BB00000  where  BB  =  00.01.10.11  then 
Output  REC E I VED_TRAN SPO  RT_DA TA_PACKE T 
ELSEIF  MSGFLG  =  00110000  then 

Output  RECE IVED_TRAN  SPO RTJDAT A_PACKET 
ELSEIF  MSGFLG  =  00010000  then 

Output  RECEIVED_TRANSPORT_PATA_PACKET 
ELSEIF  MSGFLG  =  00010100  or  00000100  then 

Output  RECEIVED_TRAN  SPORT_ACKNOWLEDGE_PACKET 
ELSEIF  MSGFLG  =  00011000.  00101000.  00111000.  or  01001000  then 
Output  RECEIVED_TRANSPORT_CONTROL_PACKET 
ELSEIF  MSGFLG  =  0101100  with  a  STARTTYPE  of  1  or  2  then 
Output  RECEIVED_TRANSPORT_INITIALIZATIONJPACKET 
ELSE  Null 


PROCESS  NAME:  DECODE  DIALOGUE  MESSAGE 

PROCESS  NUMBER:  1.3. 1.1 

PROCESS  DESCRIPTION: 

IF  Input  =  command  format  then 
Output  appropriate  command: 
ENTERJ!AINTENANCE_MODE 
CONNECT_REQUEST 
OPERATOEL.PAS  SWORD_COMMAND 
OPERATOR_START_COMMAND 
ABORT_COMMAND 
DISCONNECT_REQUEST 

ELSE  output  input  aa  INCOMING  J)IALOGUE_PACKET 


PROCESS  NAME:  EXAMINE  ADJACENT  NODE  PARAMETERS  AND  DECODE 

PROCESS  NUMBER:  1.3. 1.2 

PROCESS  DESCRIPTION: 

IF  ADJACENT_NODE_?ARAMETER  if  equal  to  LINK.INACCES SABLE  then 
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Output  LINK_INACCESSABLE_ERROR 
ELSEIF  Input  =  dialogue  data  thea 
Output  INCOMING_DIALOGUE_DATA 
ELSE  output  INCOMING  JDIALOGUE_IKTERMJPT 


PROCESS  NAME:  BREAK  DIALOGUE  DATA  INTO  SEGMENTS 

PROCESS  NUMBER:  1.3. 1.3 

PROCESS  DESCRIPTION: 

TAKE  INCOMINGJDIALOGUEJQATA  and  break  into  segments  according  to  the  maximum 
segment  length  the  node  can  handle. 

Output  each  segment  as  INCOMING_DIALOGUE_SEGMENT . 

Output  the  total  number  of  segments  the  message  has  been  broken  up  in 
as  the  SEGMENT_COUNT 


PROCESS  NAME:  EXAMINE  DATA  FLOW  CONTROL  PARAMETERS 

PROCESS  NUMBER:  1.3. 1.4 

PROCESS  DESCRIPTION: 

IF  FLOW_CONTROL .PARAMETERS  is  set  to  closed  then 
Output  DATA_JLOW_ERROR 

ELSEIF  FLOW_CONTROL_PARA METERS  DATA^REQUEST_COUNT  is  greater  than  0  then 
Decrement  the  DATA_REQUEST_COUNT  and 

Output  the  INCOMING_DIALOGUE_SEGMENT  as  TRAN SPORT_DATA_SEGMENT 
ELSE  output  DATA_FLOW_ERROR 


PROCESS  NAME:  PIGGYBACKED  DATA  ACKNOWLEDGE 

PROCESS  NUMBER:  1.3. 1.5 

PROCESS  DESCRIPTION: 

IF  Input  =  DATA^ACKJPACKET  or  DATAJNAK_PACKET  then 

Output  TRANSPORT_DATA_SEGMENT  with  the  appropriate  ACKNUM  field  set 
ELSE  output  PIGGYBACKED jraANSPORTJATA_SEGMENT  with  a  null  ACKNUM  field 


PROCESS  NAME:  ASSIGN  SEGMENT  NUMBER  MOD  4096 

PROCESS  NUMBER:  1.3. 1.6 

PROCESS  DESCRIPTION: 

IF  TRANSMITJD_FILE  <4096  then 

TRANSMIT  _D_FILE  =  TRANSMIT_D_FILE  +  1 
DA  TA_NAK_F I L E  =  TRANSMIT_D_FILE  +  1 
Output  COUNT ED_TRANSPORT_DATAwSEGMENT 
IF  last  segment  then 

Output  TRANSMIT_P_FILE  value  to  LS_FILE 
ELSE  Null 

ELSE  TRANSMIT_D_FILE  =  0 

DATAJIAK_FILE  =  1 
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Output  COUNT ED JTRANSPORT_PATA_SEGMENT 
IF  last  segment  then 

Output  TRANSMIT_D_FILE  value  to  LS_FILE 
ELSE  Null 


PROCESS  NAME:  LOAD  AND  DELETE  DATA  MEMO BY 

PROCESS  NUMBER:  1.3. 1.7 

PROCESS  DESCRIPTION: 

IF  Input  =  COUNT EDJTRAN SP 0 RTJ3A TA^S EGMENT  then 
Output  to  memory 

ELSEIF  Input  =  ACK.J>_FILE  value  then 

Delete  all  COUNT EDJTRAN SPORT  JDATA_SEGMENTS  that  have  the  same  or  lower 
values  i:or  segment  numbers 
ELSE  Input  =  START_DATA  flag  then 

Output  all  recorded  COUNTED_TRAN SPORT_DATAb_SEGMENTS  with  segment  numbers 
equal  to  or  greater  than  the  DATAk_NAK_FILE  value  as  RETRANSMITTED. 
DATA^PACKET.  All  COUNT ED.TRAN SPORT J)ATAJ3EGMENTS  with  segment 
numbers  less  than  the  DATAWNAK_JILE  value  are  deleted. 


PROCESS  NAME:  CHECK  DATA  RETRANSMIT 

PROCESS  NUMBER:  1.3. 1.8 

PROCESS  DESCRIPTION: 

IF  DATAJIAR_FILE  =  TRANSMIT JD.FILE  +  1  then 

Output  COUNT ED_TRAN SPO RT_DA TA_PACKE  T  as  TRAN SMITTED.DATAJPACKET 
ELSE  the  DATAJIAKJTILE  value  will  be  substracted  from  the  TRANSMIT_I/L_FILE 
value  and  this  value  will  be  used  to  increment  the 
FTOW_CONTROL_PARA METERS  DATA_REQUEST_COUNT  value. 

Output  STARTJDATA  flag 

Buffer  all  incoming  COUNT ED_TRANSPORT_DATA.SEGMENTS 


PROCESS  NAME:  CODE  DATA  AND  I/L  PACKETS 

PROCESS  NUMBER:  1.3. 1.9 

PROCESS  DESCRIPTION: 

IF  Input  =  RETRANSMITTED JIATA^PACKETS ,  TRANSMITTED _DATA_PACKETS . 
RBTRANSMITTED_I/L_PACKET,  or  TRAN SMITTED.I /L.PACKETS  then 
Output  as  TRAN SMITTED  JTRAN  SPO  RT_DATA_PACKET 

ELSE  Null 


PROCESS  NAME:  EXAMINE  INTERRUPT  FLOW  CONTROL  PARAMETERS 

PROCESS  NUMBER:  1.3. 2.1 

PROCESS  DESCRIPTION: 

IF  FLOW_CONTROL_PARAMETER  INTERRUPT JREQUEST.COU NT  is  greater  than  0  then 
Decrement  the  INTERRUPT_REQUEST_COUNT  and 
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Output  th«  INCOMING _DlALOGUE_INTERKDPT  as  TRAtISPORT_INTERRDPT_PACKET 
ELSE  output  INTERRDPT_FLOW_ERROR 


PROCESS  NAME:  GENERATE  INTERRUPT  LINK  SERVICES 

PROCESS  NUMBER:  1.3 .2. 2 

PROCESS  DESCRIPTION: 

UPON  reception  of  the  first  INCOMINGJ)IALOGUE_INTERRDPT 

Generate  and  output  an  INTERRUPT _LINK_SERVICES_PACRET  with  LS FLAGS  field 
Set.  to  INTERRDPT_REQUEST_COUNT  plus  a  START _HATA  command.  The  actual 
INTERRUPT _DATJL_COUNT  is  contained  in  the  FCVAL  field. 


PROCESS  NAME:  PIGGYBACK  I/L  ACKNOWLEDGE 

PROCESS  NUMBER:  1.3. 2. 3 

PROCESS  DESCRIPTION: 

IF  Input  =  I/L_ACK_?ACKET  or  I/L_NAKJ?ACKET  then 

Output  TRAN SPO RT_INT E RRU PT JPACKE T  with  the  apporpriate  ACKNUM  field  set 
ELSE  output  PIGGYBACKED_TRAN SPO RT_INT ERRUPT_PACKET  with  a  null  ACKNUM  field 


PROCESS  NAME:  CODE  I/L  PACKET 

PROCESS  NUMBER:  1.3. 2. 4 

PROCESS  DESCRIPTION: 

IF  Input  =  PIGGYBACKED_TRANSPORT_INTERKDPT_PACKET,  INTERRUPT J.INK_SERVICES_ 
PACKET,  or  DATA_L INK_SERV I CES  JPACKET  then 
Output  as  TRANSPORT_I/L_PACKET 

ELSE  Null 


PROCESS  NAME:  GENERATE  DATA  LINK  SERVICES 

PROCESS  NUMBER:  1.3. 2. 5 

PROCESS  DESCRIPTION: 

IF  Input  =  SEGMENT_COU NT  then 

Output  a  DATAJ,INK_SERVICES_PACKET  with  LSFLAGS  field  set  to 
DATA_REQUEST_COUNT 

Output  a  STARTJDATA  command.  The  actual  DATA_REQUEST_COUNT  value  is 
contained  in  the  FCVAL  field 
ELSEIF  Input  =  LS_CODE  then 

Output  a  DATAJLINK_SERVICES_PACKET  with  LSFLAG  field  set  to  DATA^REQUEST_ 
COUNT. 

Output  a  STOP_J)ATA  command.  The  actual  DATA*_REQUEST_COUNT  value  is  the 
amount  of  segment  space  left  over  from  filling  the  last  buffer. 

ELSE  Null 
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PROCESS  NAME:  ASSIGN  PACKET  NUMBER  MOD  4096 

PROCESS  NUMBER:  1.3 .2. 6 

PROCESS  DESCRIPTION: 

IF  TRANSMIT_I/L_FILE  <4096  then 

TRAN  SM IT_I  /L_FILE  =  TRANSMIT_I/L_FILE  +  1 
I/L_NAK_FILE  =  TRANSMIT_I/L_FILE  +  1 
Output  COUNT ED_TRAN SP 0 RT_I / L_PACKET 
ELSE  TRANSMIT_I/L_FILE  =  0 
I/L_NAK_FILE  =  1 

Output  COUNT ED_TRANSPORT_I/L_PACKET 


PROCESS  NAME:  LOAD  AND  DELETE  I/L  MEMORY 

PROCESS  NUMBER:  1.3. 2. 7 

PROCESS  DESCRIPTION: 

IF  Input  =  COUNT ED_TRANSPORT_I/L_PACKET  then 
Load  to  MEMORY 

ELSEIF  Input  =  ACK_I/L_FILE  value  then 

Delete  all  COUNTED_TRANSPORT_I/h_PACKETS  that  have  the  same  of  lower 
values  for  segment  numbers 
ELSE  Input  =  START_I/L  flag  then 

Output  all  recorded  COUNTED_TRANSPORT_I/L_PACKETS  with  segment  numbers 
equal  to  or  greater  than  the  I/L_NAK_FILE  value  as  RETRANSMITTED 
I/L_PACKETS. 

Delete  all  COUNTED_TRANSPORT_I/LL.PACKETS  with  segment  numbers  less  than 
the  I/L_NAK_JILE  value 


PROCESS  NAME:  CHECK  I/L  RETRANSMIT 

PROCESS  NUMBER:  1.3 .2. 8 

PROCESS  DESCRIPTION: 

IF  I/L-NAKJFILE  =  TRANSMIT_I/L_FILE  +  1  then 

Output  COUNT ED_TRAN SPORT_I/ L_PACKE T  as  TRAN SMITTED_I /L_PACKET 
ELSE  output  START_I/L  flag  and 

Buffer  incoming  COUNTED_TRANSFORT_I/L_PACKET 


PROCESS  NAME:  DETERMINE  DATA  PACKET  TYPE 

PROCESS  NUMBER:  1.4.1 

PROCESS  DESCRIPTION: 

IF  Input  MSGFLG  =  0BB00000  where  BB  =  00,01.10.11  then 
Output  RECEIVED_NORMAL_DATA_SEGMENT 
ELSEIF  Input  MSGFLG  =  00110000  or  00010000  then 
Output  RECEIVED_I/L_PACKET 
ELSE  Null 
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PROCESS  NAME:  DECODE  DATA  ACKNUM 

PROCESS  NUMBER:  1.4.2 

PROCESS  DESCRIPTION: 

IF  RECEIVED_NORMAL_DATA_SEGMENT  ACKNUM  field  =  NAK  then 
Output  data  segment  number  to  DATA*_NAK_FILE 
ELSEIF  RECEIVED_NORKAL_DATA_SEGMENT  ACKNUM  field  =  ACK  then 

IF  RECEIVED_NORMAL_DATA_SEGMENT  ACKNUM  value  is  greater  than  the  stored 
ACKJDJFILE  value  then 
Output  segment  number  to  the  ACK_D_FILE 
ELSE  Null 
ELSE  Null 


PROCESS  NAME:  DECODE  DATA  SEGMENT  NUMBER 

PROCESS  NUMBER:  1.4.3 

PROCESS  DESCRIPTION: 

IF  Input  data  segment  number  is  greater  than  the  RECEIVEDJDJFILE  value  then 
Update  the  RECEIVED_D_FILE  value  then 

IF  the  FLOW_CONTROL_PARA METER  DATA_FLOW_CONTROL_SWITCH  is  set  to  open 

then 

Output  VALID_NORMAL_DATA_SEGMENT  and  DATA^ACK JTL AG 
ELSE  output  CLOSED_FLOW_CONTROL 
ELSE  output  DATAt_NAK_FLAG 


PROCESS  NAME:  DECODE  I/L  SEGMENT  NUMBER 

PROCESS  NUMBER:  1.4.4 

PROCESS  DESCRIPTION: 

IF  Input  I/L  segment  number  is  greater  than  the  RECEIVED_I/L_FILE  value  then 
Update  the  RECEIVED_I/L_FILE  and 
Output  I /L_ACK_FLAG  and  VALID_I/L_PACKET 
ELSE  output  I/L_NAKJFLAG 


PROCESS  NAME:  DECODE  I/L  ACKNUMI  FIELD 

PROCESS  NUMBER:  1.4.5 

PROCESS  DESCRIPTION: 

IF  RECEIVED_I/L_PACKET  ACKNUMI  field  is  equal  to  NAK  then 
Output  stored  I/L_SEGMENT_NUMBER  to  I/L_NAK_FILE 
ELSEIF  RECEIVED_I/L_PACKET  ACKNUMI  field  is  greated  than  the  stored  ACK_I/L_ 
FILE  value  then 

Output  segment  number  to  the  ACK_I/L_FILE 
ELSE  Null 


PROCESS  NAME:  GENERATE  DATA  ACKNOWLEDGE  PACKET 

PROCESS  NUMBER:  1.4.6 
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PROCESS  DESCRIPTION: 

UPON  reception  of  a  DATA_ACK_?LAG 

Generate  and  output  a  DATA^ACKJPACKET 


PROCESS  NAME:  GENERATE  DATA  NEGATIVE  ACKNOWLEDGE  PACKET 

PROCESS  NUMBER:  1.4.7 

PROCESS  DESCRIPTION: 

UPON  reception  of  a  DATAJIAKJFLAG  or  CLOSED JFLGW_CONTROL  flag 
Output  a  DATA_NAK_PACKET 


PROCESS  NAME:  LOAD  RECEIVE  BUFFER  UNTIL  FULL  OR  LS 

PROCESS  NUMBER:  1.4.8 

PROCESS  DESCRIPTION: 

IF  receive  buffers  available  then 

Fill  until  all  data  segments  are  accounted  for  and 
Output  NORMAL_DATA_PACKET 

IF  last  receive  buffer  is  not  entirely  full  when  last  data  segment 
deposited  then 
Output  LS_CODE 
ELSE  Null 

ELSE  output  NO_BUFFER^_SPACE 


PROCESS  NAME:  GENERATE  I/L  NEGATIVE  ACKNOWLEDGE  PACKET 

PROCESS  NUMBER:  1.4.9 

PROCESS  DESCRIPTION: 

UPON  reception  of  an  I/L_NAK_FLAG 

Generate  and  output  an  I/L_NAK_PACKET 


PROCESS  NAME:  GENERATE  I/L  ACKNOWLEDGE  PACKET 

PROCESS  NUMBER:  1.4.10 

PROCESS  DESCRIPTION: 

UPON  reception  of  an  I/L_^CK_FLAG 

Generate  and  output  an  I/L_>CK_PACKET 


PROCESS  NAME:  DECODE  VALID  I/L  PACKET 

PROCESS  NUMBER:  1.4.11 

PROCESS  DESCRIPTION: 

IF  Input  MSGFLG  =  00010000  then 

Output  VALID_LINK_SERVICES_PACKET 
ELSEIF  Input  MSGFLG  =  00110000  then 

IF  INTERBUPT_REQUEST_COUNT  is  greater  than  0  then 
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Output  VALID_INTERRDPT_PACKET 
ELSE  output  INTERRUPT_ERROR 
ELSE  Null 


PROCESS  NAME:  CODE  ACKNOWLEDGE  PACKETS 

PROCESS  NUMBER:  1.4.12 

PROCESS  DESCRIPTION: 

IF  Input  =  DATA^ACK_PACKET ,  DATAWNAK_PACKET,  I/I^ACKJPACKET,  or  I/L_NAK_PACKET 
then 

Output  as  TRANSMITTED_TRAN SPORT^ ACKNOWLEDGE  PACKET 
ELSE  Null 


PROCESS  NAME:  CODE  DATA  PACKETS 

PROCESS  NUMBER:  1.4.13 

PROCESS  DESCRIPTION: 

IF  Input  =  NORMAL_DATA^_PACKET  or  VAL ID_INTERRDPT_PACKET  then 
Output  as  OUTGOING_DIALOGUE_DATAJPACKET 
ELSE  Null 


PROCESS  NAME:  DECODE  LINK  SERVICES  PACKET 

PROCESS  NUMBER:  1.4.14 

PROCESS  DESCRIPTION: 

IF  FCVAL  field  value  of  the  VALID_LINK_SERVICES_PACKET  when  added  to  the  data 
segment  request  would  result  in  a  DATA_SEGMENT_REQUEST_COUNT  greater  than 
+127  or  less  than  -127  then 
Output  LINK_SERVICES_ERROR 

ELSEIF  FCVAL  field  value  of  the  VALID_LINK_SERVICES_PACKET  when  added  to  the 
I/L  segment  request  would  result  in  a  INTERRUPT_REQUEST_COUNT  greater 
than  +127  then 
Output  LINK_SERVICES_ERROR 

ELSE  output  FCVAL  field  value  +  current  SEGMENT_REQUEST_COUNT  to  the  FLOW_ 
CONTROL_PARAMETERS_TABLE 


PROCESS  NAME:  TRANSITION  LINK  TO  ON-LINE  MODE 

PROCESS  NUMBER:  1.5.1 

PROCESS  DESCRIPTION: 

IF  Input  =  OPERATOR_START_COMMAND  then 
Output  INITIALIZER  INK  command 

ELSE  Input  =  INITIAL  IZATION_ON_OTHERRND  or  INITL.*LIZATION_COMPLETE  then 
Output  START_COMMAND 
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PROCESS  NAME:  DECODE  FUNCTIONS  FIELD 

PROCESS  NUMBER:  1.5.2 

PROCESS  DESCRIPTION: 

IF  Input  =  RECEIVED_NODE_INITIALIZATION_PACKET  with  FUNCTIONS  field  set  to 
INTERCEPT  then 

Output  RECEIVED_INTERUPT_INITIALIZATION_PACKET 
ELSE  Input  =  RECEIVED_NODE_INITIALIZATION_PACKET  with  FUNCTIONS  field  set  to 
NO_INTERCEPT  then 

Output  RECE I VED_NO_INT ERCEPT_IN IT IAL IZ AT ION_PACKE T 


PROCESS  NAME:  DECODE  INITIALIZATION  PACKET 

PROCESS  NUMBER:  1.5.3 

PROCESS  DESCRIPTION: 

IF  Input  STARTTYPE  =  1  then 

Output  RECEI VED_NODE_IN IT IAL IZ  AT ION_PACKET 
ELSE IF  Input  STARTTYPE  =  2  then 

Output  RECEIVED_NODE_VERFICATION_PACKET 
ELSEIF  Input  STARTTYPE  =  4  then 

Output  RECEIVED_CORRECT_PAS  SWORD_COMMAND 
ELSEIF  Input  STARTTYPE  =  5  then 

Output  RECEIVED_INCORRECT_PASSWORD_COMMAND 
ELSE  Input  STARTTYPE  =  3  then  Null 


PROCESS  NAME.  GENERATE  NODE  INITIALIZATION  PACKET  VERIFY  =  0 

PROCESS  NUMBER:  1.5.4 

PROCESS  DESCRIPTION: 

IF  Input  =  ST ART_COMMAND  or  VERIFY_CLEAR  flag  then 
Output  NODE_INITIALIZATION_VO_PACKET 
ELSE  Null 


PROCESS  NAME:  DECODE  REMAINING  FIELDS 

PROCESS  NUMBER:  1.5.5 

PROCESS  DESCRIPTION: 

IF  Input  =  RECEIVED_INTERCEPT_INITIALIZATION_PACKET  then 
Send  required  field  values  to  IN IT IAL_PARAMETERWLIST 
IF  VERIFY  field  =  1  then 

Output  VERIFY_SET  flag 
ELSE  output  VERIFY_CLEAR  flag 
ELSE  Null 


PROCESS  NAME: 
PROCESS  NUMBER: 
PROCESS  DESCRIPTION 


GENERATE  NODE  VERIFICATION  PACKET 
1.5.6 


IF  Input  =  VERIFY_SET  then 

Take  OPEKATOR^PAS  SWORD_COMMAND  and 
Generate  and  output  NODE_VERIFICATION_PACKET 
ELSE  Null 


PROCESS  NAME:  GENERATE  NODE  INITIALIZATION  PACKET  VERIFY  =  1 

PROCESS  NUMBER:  1.5.7 

PROCESS  DESCRIPTION: 

IF  Input  =  RECEIVED_NO_INTERCEPT_INITIALIZATION_PACKET  then 

Decode  fields  and  place  values  in  INITIAL_PARAMETER_LIST  and 
Generate  and  output  NODE_INITIALIZATION_Vl_PACKET 
ELSE  Null 


PROCESS  NAME:  DECODE  PASSWORD 

PROCESS  NUMBER:  1.5.8 

PROCESS  DESCRIPTION: 

IF  PASSWORD  field  of  a  RECEIVED_NODE_VERIFICATION_PACKET  contains  the  correct 
password  then 

Output  the  password  to  the  SATELLITE^ NODE_PARAMETERS_TABLE  and 
Output  C 0 RRECT_PAS  SW 0 RD_C OMMAND 
ELSE  output  INCORRECT_PAS SWORD_COMMAND 


PROCESS  NAME:  CODE  INITIALIZATION  PACKETS 

PROCESS  NUMBER:  1.5.9 

PROCESS  DESCRIPTION: 

IF  Input  =  NODE_INITIALIZATION_VO JPACKET ■  NODE_VERIFICATION_PACKET,  NODE. 
INITIAL IZATION_Vl_PACKET»  CORRECT_PASSWORD_COMMAND.  or  INCORRECT 
PAS  SWORD_COMMAND  then 

Output  as  TRANSMITTED_TRANSPORT_INITIALIZATION_PACKET 
ELSE  Null 


PROCESS  "AME:  GENERATE  CONNECT  INITIATE  PACKET 

PROCESS  NUMBER:  1.6. 1.1 

PROCESS  DESCRIPTION: 

IF  Input  -  CONNECT_REQUEST  command  then 
Output  CONNECT_INIT I ATE_PACKE T 
ELSE  Null 


PROCESS  NAME: 
PROCESS  NUMBER: 
PROCESS  DESCRIPTION 


DECODE  CONTROL  PACKET 

1.6. 1.2 


IF  Input  MSGFLG  =  00011000  then 

Output  RECEIVED_CONNECT_INITIATE_PACKET 
ELSEIF  Input  MSGFLG  *  00101000  then 

Output  RECEIVED_CONNECT_CONFIRM_PACKET 
ELSEIF  Input  MSGFLG  *  00111000  then 

Output  RECEIVED JISCONNECT_INITIATE__PACKET 
ELSE  Input  MSGFLG  =  01001000  then 

Output  RECEIVED_DISCONNECT_CONFIRM_PACRET 


PROCESS  NAME:  DECODE  CONNECT  INITIATE  PACKET 

PROCESS  NUMBER:  1.6. 1.3 

PROCESS  DESCRIPTION: 

PASS  SOCRCE_NAME,  SOURCE_PROCESS_IDENTIFICATION,  DESTINATION_PROCESS_ 
IDENTIFICATION,  REPLY_IDENTIFIERS,  ACCESS_CONTROL_INFORMATION,  and 
REMOTEJPROCESS ’ S_SEGMENT_SIZE  to  the  DIALOGUE_PROCESS_TABLE 
PASS  SERVICES  to  the  FLOW_CONTROL_PARAMETERS_TABLE 
IF  the  follovng  errors  apply  then 
Output  a  RE J ECT__CONNECT  flag 

1.  Resource  allocation  failure 

2.  Destination  node  does  not  exist 

3.  Node  shutting  down 

4.  Destination  process  does  not  exist 

5.  Invalid  process  name  field 

6.  Destination  process  queue  overflow 

7 .  Too  many  connections  to  node 

8.  Too  many  connections  to  destination  node 

9.  Access  not  perm it ted -unacceptable  RQSTRID  or  PASSWORD 

10.  Unacceptable  ACCOUNT  information 

11.  Dialogue  process  aborted,  timedout,  or  cancelled  request 

12.  No  path  to  destination  node 

13.  Image  data  field  too  long 
ELSE  output  an  ACCEPT_CONNECT  flag 


PROCESS  NAME:  DIALOGUE  PROCESS  EXTERNAL  END 

PROCESS  NUMBER:  1.6. 1.4 

PROCESS  DESCRIPTION: 

IF  Input  =  DISCONNECT_REQUEST  then 

IF  ACK_D_FILE  value  equals  the  LS_FILE  value  then 
Output  a  STOP  flag 
ELSE  hold  DISCONNECT_REQUEST 
ELSE  Null 


DECODE  CONNECT  CONFIRM  PACKET 
1.6. 1.5 


PROCESS  NAME: 
PROCESS  NUMBER: 
PROCESS  DESCRIPTION 
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IF  the  following  errors  apply  then 
Output  a  REJECT_CONFIRM  flag 

1.  Segsize  too  small 

2.  Dialogue  process  aborted.  timedout,  or  cancelled 

3.  DSTADDR  logical  link  does  not  exist 

4.  Image  data  field  too  long 
ELSE  output  an  ACCEPT_CONFIRM  flag 

Update  the  FLOW_CONTROL_PARAMETERS_TABLE 

Signal  ADJACENT_NODE_PARAMETERS  that  values  are  valid 


PROCESS  NAME:  GENERATE  CONNECT  CONFIRM  PACKET 

PROCESS  NUMBER:  1.6. 1.6 

PROCESS  DESCRIPTION: 

UPON  successful  reception  of  an  ACCEPT_CONNECT  flag 

Generate  and  output  a  CONNECT_CONFIRM_PACKET  using  data  in  the  DIALOGUE_ 
PROCESS_TABLE 


PROCESS  NAME:  GENERATE  DISCONNECT  INITIATE  PACKET 

PROCESS  NUMBER:  1.6. 1.7 

PROCESS  DESCRIPTION: 

IF  Input  =  RE J ECT_CONNECT  then 

Output  a  DIS CONNECT_INIT IATE_PACKET  with  REASON  as  listed  in  process 
1 .6.1.3 

ELSEIF  Input  =  REJECT_CONFIRM  then 

Output  a  DISCONNECT_INITIATEJ?ACKET  with  REASON  as  listed  in  process 
1.6. 1.5 

ELSEIF  Input  =  PERSISTENTJERROR  then 

Output  a  DISCONNECT_INITIATE_PACKET  reason:  "Third  party  aborted  the 
logical  link" 

ELSEIF  Input  =  STOP  then 

Output  a  DISCONNECT_INITIATE_PACKET  with  reason:  "Third  party  aborted 
the  logical  link" 

ELSEIF  Input  =  ABO RT_COMMAND  then 

Output  a  DISCONNECT_INITIATE_PACKET  with  reason:  "Link  aborted  by 
dialogue  process" 

ELSEIF  Input  =  INTERRUPT_ERROR  then 

Output  a  DISCONNECT_INITIATE_PACKET  with  reason  as  listed  in  REASON  table 
ELSE  Input  =  LINK_SERV ICE S_ERROR  then 

Output  a  DISCONNECT_INITIATE_PACKET  with  reason  as  listed  in  REASON  table 


PROCESS  NAME:  CODE  CONTROL  PACKETS 

PROCESS  NUMBER:  1.6. 1.8 

PROCESS  DESCRIPTION: 

IF  Input  =  connect_initlate_packet,  CONNECT_CONFIRM_PACKET, 

DISCONNECT_INITIATE_PACKET,  or  DISCONNECT_CONFIRMJPACKET  then 
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Output  as  TRANSMITTED_TRANSPORT_CONTROL_PACKET 
ELSE  Null 


PROCESS  NAME:  DECODE  DISCONNECT  CONFIRM  PACKET 

PROCESS  NUMBER:  1.6. 2.1 

PROCESS  DESCRIPTION: 

DECODE  REASON  Field  and 

PASS  to  DIALOGUE_PROCESS 
SHUT-DOWN  the  logical  link 


PROCESS  NAME:  DECODE  DISCONNECT  INITIATE  PACKET 

PROCESS  NUMBER:  1.6. 2. 2 

PROCESS  DESCRIPTION: 

IF  REASON  field  =  "link  aborted  by  dialogue  process"  then 
Output  REASON  to  DIALOGUEJPROCESS  and 
Output  an  ABORT  flag 

ELSE  Pass  error  reason  to  DIALOGUE_PROCESS  and 
Output  a  NO_ABORT  flag 


PROCESS  NAME:  DIALOGUE  PROCESS  END 

PROCESS  NUMBER:  1.6 .2. 3 

PROCESS  DESCRIPTION: 

IF  Input  =  NO_ABORT  then 

IF  ACK_D_FILE  value  =  LSJFILE  value  then 
Output  STOP_LINK_NOW  flag 
ELSE  hold  NO_ABORT  flag 
ELSE  Null 


PROCESS  NAME:  GENERATE  DISCONNECT  CONFIRM  PACKET 

PROCESS  NUMBER:  1.6. 2. 4 

PROCESS  DESCRIPTION: 

IF  Input  =  ABORT  flag  or  ST0P_LINK_N0W  flag  then 

Output  a  DISCONNECT_CONFIRMJPACKET  vith  reason:  “Confirmation  of 
disconnect  initiate" 

Output  a  STOP_LINK  command  to  shut  down  the  physical  link 
ELSE  Null 


PROCESS  NAME:  DETERMINE  ACKNOWLEDGE  TYPE 

PROCESS  NUMBER:  1.7.1 

PROCESS  DESCRIPTION: 

IF  Input  MSGFLG  =  00000100  then 
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Output  as  RECEIVED_NORMAL_DATA^ACK_?ACKETS 
ELSE  Input  MSGFLG  =  00010100  then 

Output  as  RECEIVED_I/I^ACK ^PACKET 


PROCESS  NAME:  DECODE  DATA  ACK  PACKET 

PROCESS  NUMBER:  1.7.2 

PROCESS  DESCRIPTION: 

DECODE  ACKNUM  field 
IF  =  1  then 

Output  associated  value  to  ACK_PJFILE 
ELSE  =  2  then 

Output  associated  value  to  DATAb_NAK_FILE 


PROCESS  NAME:  DEC0DE_I/LJ1CK_PACKET 

PROCESS  NUMBER:  1.7.3 

PROCESS  DESCRIPTION: 

DECODE  ACKNUMI  field 
IF  =  1  then 

Output  associated  value  to  the  ACK_I/L_FILE 
ELSE  =  2  then 

Output  associated  value  to  the  I/L_NAK_JFILE 


PROCESS  NAME:  EXAMINE  DSTADDR  FIELD 

PROCESS  NUMBER:  1.8.1 

PROCESS  DESCRIPTION: 

IF  DSTADDR  =  AD JACENT_NODE_jAD DRESS  then 
Output  as  ADJACENT_NODE_PACKETS 
ELSEIF  INITIALIZATION_PACKETS  then 
Output  as  ADJACENT_NODE_PACKETS 
ELSEIF  DSTADDR  =  NONADJACENT_.NODEJU)DRESS  then 
Output  as  NONADJACENT_N0DE_PACKETS 
ELSE  Input  =  CONNECT_INITIATE_PACKET  then 
Output  as  NONADJACENT_NODE_PACKETS 


PROCESS  NAME:  ADD  RTHDR  FIELD 

PROCESS  NUMBER:  1.8.2 

PROCESS  DESCRIPTION: 

IF  Input  =  NONADJACENT_NODE_PACKETS  then 
Refer  to  DIALOGUE_PROCESS_TABLE  and 
Extract  DSTNODEJIAME 
Output  RTHDRJ10NADJACENT_N0DE_PACKETS 
ELSE  Null 
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PROCESS  NAME:  IS  ROOTING  NECESSARY  AND  PRESENT 

PROCESS  NUMBER:  1.8.3 

PROCESS  DESCRIPTION: 

IF  Input  DSTNODE  name  =  the  name  of  a  satellite  not  adjacent  to  this  node  then 
Output  as  NONADJACENT_ROCTE_PACKET 
ELSE  output  as  NONADJACENT_SATELLITR_PACKETS 


PROCESS  NAME:  PASS  TO  CORRECT  ADJACENT  NODE 

PROCESS  NUMBER:  1.8.4 

PROCESS  DESCRIPTION: 

IF  Input  =  AD JACENT_NODE_PACKE TS  or  NONADJACENT_SATELLITE_PACKETS  then 
Output  as  OUTGOING_SATELLITE_TRANSPORT_PACKET 
Output  a  TSANSMIT_PACKET  command 
Output  a  RECEIVE.PACKET  command 
ELSE  Null 


PROCESS  NAME:  CODE  OUTGOING  DIALOGUE  MESSAGE 

PROCESS  NUMBER:  1.9 

PROCESS  DESCRIPTION: 

IF  Input  =  FLOW_CONTROL_ERRORS ,  OUTGOING_DI ALOGUE_DATA_PACKET ,  RECEIVED. 

INCORRECT.PAS SWORD.COMMAND .  ERROR.REASON,  or  TRAN SIENT_ERROR_THRESHOLD_ 
COUNTER.OVERFLOW  then 

Output  above  as  OUTGOING.DI ALOGUE.ME S SAGE 
ELSE  Null 


PROCESS  NAME:  SEND  TO  NETWORK  PROTOCOL 

PROCESS  NUMBER:  1.10 

PROCESS  DESCRIPTION: 

IF  Input  =  OUTGOING_TRANSPORT_ROUTE_PACKET  or  NONADJACENT_ROUTE_PACKET  then 
Output  OUTGOING_NODE_TRAN SPO RT.PACKET 
ELSE  Null 


PROCESS  NAME:  DECODE  MESSAGE  TYPE 

PROCESS  NUMBER:  2.1 

PROCESS  DESCRIPTION: 

IF  Input  =  NETWORK JEEADER  then 
Output  a8  NETWORK_PACKET 
ELSE  Input  =  ROUT E_PEADE R  then 
Output  as  a  ROUTING_PACKET 


PROCESS  NAME:  CHECK  R-HOP  COUNT  =  2 

PROCESS  NUMBER:  2.2 

PROCESS  DESCRIPTION: 

IF  Input  HOP_COUNT  field  is  less  than  or  equal  to  2  then 
Output  VALID_ROCTING_PACKET 
ELSE  Null 


PROCESS  NAME:  DECODE  NETWORK  HEADER 

PROCESS  NUMBER:  2.3 

PROCESS  DESCRIPTION: 

IF  Input  NETWORK  layer  header  destination  field  value  relates  to  an  adjacent 
satellite  node  then 

Output  as  INCOMING_NODE_TRANSPORT_PACKET  after  stripping  off  the  network 
header 

ELSE  output  as  NE TWO RK_T 0_NE TW 0 RK JPACKET 


PROCESS  NAME:  INCREMENT  HOP 

PROCESS  NUMBER:  2.4 

PROCESS  DESCRIPTION: 

INCREMENT  value  in  HO?  COUNT  field  by  1  and 
Output  as  HOPPED_ROUT ING ^PACKET 


PROCESS  NAME:  UPDATE  ROUTING  TABLE  IF  NEW 

PROCESS  NUMBER:  2.5 

PROCESS  DESCRIPTION: 

IF  VALIDJROUTINGJPACKET  liue  cost  value  is  different  from  what  is  located  in 
ROUT ING_TABLE__2  link  cost  value  for  the  particular  link  then 
Update  to  the  correct  ROUT ING_TABLE_2  value 

Calculate  and  update  1-2-3 ,  2-3-1*  and  3-1-2  values  if  possible 
ELSE  Null 


PROCESS  NAME:  DETERMINE  LEAST  COST  LINK 

PROCESS  NUMBER:  2.6 

PROCESS  DESCRIPTION: 

FROM  the  OUTGOING_NODE_TRAN SPO RT_PACKET  RTHDR  field  use  the  NODENAME  to 
Determine  the  least  cost  link 
Output  TRANSPORT_?ACKET 
ELSE  Null 


PROCESS  NAME:  ADD  NETWORK  HEADER 
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PROCESS  NUMBER:  2.7 

PROCESS  DESCRIPTIONS 
IF  Input  =  TRAN SPO RT_PACKET  then 
Add  network  layer  header  and 

Send  out  as  TRANSPORT_TO_NETWORK_PACKET.  HOP  =  1 
ELSE  Null 


PROCESS  NAMES  SEND  OLD  VALUES  OUT  OVER  NEW  INITIALIZED  LINE 

PROCESS  NUMBERS  2.8 

PROCESS  DESCRIPTIONS 

IF  node  senses  that  initialization  just  took  place  over  a  new  routing  line 
then 

IF  RdJTING_TABLE_2  has  existing  values  then 
Generate  and  output  OLD_ROUTING_PACKETS 
ELSE  Null 
ELSE  Null 


PROCESS  NAMES  CHECK  N-HOP  COUNT  «  2 

PROCESS  NUMBER:  2.9 

PROCESS  DESCRIPTIONS 

IF  Input  HOPS  field  is  less  than  or  equal  to  2  then 

Output  as  VALID_NETWORK_TO_NETWORKJPACKET 
ELSE  Null 


PROCESS  NAMES  UPDATE  NETWORK  HEADER 

PROCESS  NUMBER:  2.10 

PROCESS  DESCRIPTION: 

IF  Input  =  VALID_NETWORK_TO_NETWORK_PACKET  then 

Compare  existing  destination  code  in  the  network  header  against  the  line 
cost  in  R0UTING_TABLE_2  then 
Output  over  the  correct  ROUTING_LINE 

ELSE  Null 


PROCESS  NAMES  EVERY  TIMER  INTERVAL  UPDATE  ADJACENT  LINE 

PROCESS  NUMBER:  2.11 

PROCESS  DESCRIPTION: 

AT  the  end  of  every  preset  timer  interval 
check  ROUT ING_TABLE_2 

IF  values  present  then 

Output  ADJACENT_NODE_ROUTING_PACKETS  on  all  routing  links. 
HOP  =  1 
ELSE  Null 


323 


PROCESS  NAME:  ISSUE  CORRECT  LINE  COST  OVER  ALL  LINES 

PROCESS  NUMBER:  2.12 

PROCESS  DESCRIPTION: 

IF  Input  s  STOP_LINR  command  or  INITIALIZE_LINE  command  then  refer  to  ROUTING.. 
TABLE_1  and  get  the  cost  associated  with  the  specific  link. 

Generate  and  output  INITIAL_ROUTE_PACKET 
ELSE  Null 


PROCESS  NAME:  SEND  PACEET  OVER  CORRECT  LINE(S) 

PROCESS  NUMBER:  2.13 

PROCESS  DESCRIPTION: 

IF  Input  =  INITIAL_ROUTE_PACKET,  VALID_NETWORK_PACEET ,  HOPPED_ROUTIN  _PACEET, 
ADJACENT_NODE__ROUTING_PACKET ,  0LD_R0UT ING_PACEETS .  or  TRANSPORT_TO_ 
NETWORK_PACKET  then 

Output  it  as  a  OUTGOING_NODE_NETWORK_PACKET 
ELSE  Null 


PROCESS  NAME:  EXECUTE  NETWORE  PROTOCOL  AT  SECONDARY  NODE 

PROCESS  NUMBER:  3.0 

PROCESS  DESCRIPTION: 

USE  the  established  ROUTING  ALGORITHM  to  route  packets  from  SECONDARY_INCOMING 
_NODE_NETVORK_PACKET  to  SECONDARY_INCOMING_NODE„TRANSPORT_PACKET  or 
SECONDARY_OUTGOING_NODE_NETWORE_PACEET.  Also  route  packets  from 
SECONDARY_OUTGOING_TRANSPORT_PACEET  to  SECOND  ARY_OUTGOING_NODE_NETWORK_ 
PACEET.  Routing  packets  are  generated  internally  to  keep  all  routing 
tables  up-to-date. 


PROCESS  NAME:  EXECUTE  TRANSPORT  PROTOCOL  AT  SECONDARY  NODE 

PROCESS  NUMBER:  4.0 

PROCESS  DESCRIPTION: 

USED  to  take  a  SECONDARY_INCOMING_DIALOGUE_MESSAGE  or  SECONDARY_INCOMING_ 

NODE_TRANSPORTJPACEET  or  SECONDARY_INCOMING_SATELLITE_TRANSPORT_PACKET 
and  create  the  necessary  envelope  for  accurate  interprocess  communication 
Outputs  can  be  SECONDARY_OUTGOING_TRANSPORT_PACRET  or  SECONDARY_OUTGOING_ 
NODE_TRAN SPO RT_PACEE T  or  SECONDARY_OUTGOING_DIALOGUE_MESSAGE . 
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DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 

NOTES: 


DATA  FLOW  NAME: 
ALIASES : 
COMPOSITION: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES : 

VALDES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES: 


ABDTTED_PACKET 
F  OLLOWON_PACKET 
SYNC_PACKET 
LINK_PACKETS 

SEE  ALIASES 

DECODE  AND  SYNC  INCOMING  BIT  STREAM  LAYER 


ACK_PACKET 

RECEIVED_ACR_PACKET 

ACKJPACKET  =  ENQ  +  ACKTYPE  +  ACKSDB  +  FLAGS  +  RESP  + 
FILL  +  ADDR  +  BLKCK3 
EXECUTE  OUTGOING  CONTROL  PACKET  LAYER 
FRAME  PRIMARY  INFORMATION  PACKET  LAYER 


ACKSUB 

NONE 

ACK  SUBTYPE  =  00000000 
ALL  LINK  LAYERS 


ACKTYPE 

NONE 

ACK  PACKET  TYPE  VALUE  =  00000001 
ALL  LINK  LAYERS 


ADDR 

NONE 

ALWAYS  EQUALS  1 
ALL  LINK  LAYERS 


AGREE 

NONE 

A  FLAG  USED  TO  ISSUE  AN  ACKJ?ACKET  SINCE  THE  LAST 
SEQUENTIAL  NUMBERED  DATA  PACKET  SENT  AGREES  WITH  THE 
NUMBER  OF  THE  LAST  SEQUENTIAL  PACKET  RECEIVED. 
EXECUTE  INCOMING  CONTROL  PACKET  LAYER 
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DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


BLKCJC1 

NONE 

THE  BLOCK  CHECK  ON  THE  NUMBERED  PACKET  HEADER.  IT  IS 
COMPUTED  ON  SOH  THROUGH  ADDR  USING  THE  CRC-16  POLYNOMIAL 
(X"16  +  X~15  +  X"2  +  1).  BLKCK1  IS  INITIALIZED  TO  ZERO 
PRIOR  TO  COMPUTATION  AND  TRANSMITTED  X  15  BIT  FIRST.  ON 
RECEPTION  THE  INCLUSION  OF  BLKCK1  IN  THE  COMPUTATION  WILL 
RESULT  IN  A  ZERO  REMAINDER  OR  CRC  IF  NO  ERRORS  EXIST. 

ALL  LINK  LAYERS 


BLKCK2 

NONE 

THE  BLOCK  CHECK  ON  THE  DATA  FIELD.  COMPUTED  ON  THE  DATA 
FIELD  ONLY  USING  THE  TECHNIQUE  DESCRIBED  FOR  BLKCK1. 

ALL  LINK  LAYERS 


BLKCK3 

NONE 

THE  BLOCK  CHECK  ON  THE  CONTROL  PACKET.  BLKCK3  IS 
COMPUTED  ON  FIELDS  ENQ  THROUGH  ADDR  USING  THE  TECHNIQUE 
DESCRIBED  IN  BLKCK1. 

ALL  LINK  LAYERS 


CLEAR 

NONE 

A  FLAG  USED  TO  CLEAR  THE  SNAK  FLAG  FILE  OR  THE  SACK  FLAG 

FILE  OR  THE  SREP  FLAG  FILE 

EXECUTE  OUTGOING  CONTROL  PACKET  LAYER 

FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 


COUNT 

NONE 

SPECIFIES  THE  NUMBER  OF  BYTES  IN  THE  DATA  FIELD.  A  VALUE 
OF  0  IS  NOT  ALLOWED. 

ALL  LINK  LAYERS 


327 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 

NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS : 
NOTES: 


COUNT ED_LINK_DATA_PACKET 
<  256 JLINK_PACRET 
RETRAN SMITTED_PACKETS 

NOSYNC_PRIMARY_TO_SECONDARY_DATA_PACKET 

CODNTED_LINK_DATA_PACKET  =  LINK_DATA_PACKET  +  RESP  +  NDM 
FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 


DATA 

NONE 

THE  NDMBERED  PACKED  DATA  FIELD.  THIS  FIELD  IS  TOTALLY 
TRANSPARENT  TO  THE  PROTOCOL  AND  HAS  NO  RESTRICTIONS 
EXCEPT  TO  CONTAIN  THE  NDMBER  OF  BYTES  SPECIFIED  IN  THE 
COD NT  FIELD. 

ALL  LINK  LAYERS 


DISABLE_LINK 

NONE 

DISCONNECTS  THE  DRIVER  FROM  THE  LINK  PROTOCOL. 
START  REPLY  TIMER  LAYER 


DISAGREE 

NONE 

A  FLAG  PLDS  THE  NDMBER  OF  THE  LAST  SEQDENTIAL  PACKET  THAT 
WAS  RECEIVED.  DSED  TO  ISSDE  A  NAK_PACKET  SINCE  THE  LAST 
SEQDENTIALLY  NDMBERED  DATA  PACKET  SENT  DID  NOT  AGREE  WITH 
THE  LAST  SEQDENTIAL  PACKET  RECEIVED. 

EXECDTE  INCOMING  CONTROL  PACKET  LAYER 


DLE 

NONE 

MAINTENANCE  PACKET  IDENTIFIED  =  10010101 

ALL  LINK  LAYERS 
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DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES : 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 


NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


DLE_PACKET 
VALID_DLE_PACKET 
TRAN  SMIT_DLE_PACKET 

DLE_PACKET  =  DLE  +  COUNT  +  FLAGS  +  FILL  +  FILL  +  AD DR  * 
BLKCK1  +  DATA  +  BLKCK2 
DECODE  AND  SYNC  INCOMING  BIT  STREAM  LAYER 
FRAME  SECONDARY  INFORMATION  PACKETS  LAYER 
EXECUTE  MAINTENANCE  PACKET  LAYER 


ENABLE_LINK 

NONE 


CONNECTS  THE  DRIVER  TO  THE  LINK  PROTOCOL 
ALL  LINK  LAYERS 


ENQ 

NONE 

UNNUMBERED  CONTROL  PACKET  IDENTIFIER  =  00000101 
ALL  LINK  LAYERS 


enqjpacket 

VALID_ENQ_PACKET 

valid_crc_enq_packet 

VALID  JLENGTH_ENQ_HEADER 

ENQ_PACKET  =  ENQ  +  TYPE  +  SUBTYPE  +  FLAGS  +  RCVR  + 
SNDR  +  ADDR  +  BLKCK3 

DECODE  AND  SYNC  INCOMING  BIT  STREAM  LAYER 
FRAME  SECONDARY  INFORMATION  PACKETS  LAYER 
EXECUTE  INCOMING  CONTROL  PACKET  LAYER 


ENQ/DLE_SYNC_PACKET 

QSYNC_ENQ/DLE_PACKET 


ENQ/DLE_SYNC_PACKET  =  4{SYNC}  + 


TRANSMIT_DLE_PACKET 

P AD / STRT_PACKET 

MOP_PACKET 

REP_PACKET 

STACK_PACKET 

ACK_PACKET 

NAK_PACKET 
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NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES: 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 


NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 


ENTER_MAINTENANCE_MODE 

NONE 

CHANGE  FROM  ON-LINE  MODE  TO  OFF-LINE  MAINTENANCE  MODE 
EXECDTE  MAINTENANCE  PACKET  LAYER 


FILL 

NONE 

FILL  BYTE  WITH  VALUE  OF  0 
ALL  LINK  LAYERS 


FLAGS 

NONE 

LINK  FLAGS  TO  CONTROL  OWNERSHIP  AND  PACKET 
SYNCHRONIZATION 

BIT  0  =  QUICK  SYNC  FLAG  -  QSYNC 

BIT  1  =  SELECT  FLAG  =  OWNERSHIP  (MOST  BE  PRESENT  ON  DLE 

AND  ENQ  PACKETS,  DON'T  CARE  IN 
SOH_PACKET) . 

ALL  LINK  LAYERS 


FOLLOW  ON_PACKET 
SYNC_PACKET 
ABUTTED_PACKET 
LINK_PACKETS 

FOLLOWONJ?ACKET  =  I  SOH_PACKET  I 
I  DLE_PACKET  | 

I  ENQ_PACKET  I 

DECODE  AND  SYNC  INCOMING  BIT  STREAM  LAYER 


FRAMING_ERRORS 

NONE 

FRAMING_ERRORS  =  7~ I HEADER^_FORMAT_ERROR  I 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 


1 


I  INVALIDJ)ATA_LENGTH  | 

!  INVALID JDLE_PACKET  I 
I  INVALID_BLKCK 1  I 

I  INVAL ID_BLKCK  2  I 

I  INVALID_BLKCK3  I 

EXECUTE  HDLC  PROTOCOL  AT  PRIMARY  NODE  LAYER 


HEADER_FORMAT_ERROR 

NONE 

FLAGS  AN  INCORRECTLY  RECEIVED  HEADER_LENGTH  FIELD.  AN 
NAK_PACKET  IS  GENERATED. 

FRAME  SECONDARY  INFORMATION  PACKETS  LAYER 
EXECUTE  CONTROL  INCOMING  PACKET  LAYER 


IDENTIFY 

NONE 

USED  TO  PASS  A  SET  OR  CLEAR  CONDITION  FROM  SNAK  FLAG  FILE 
OR  SACK  FLAG  FILE  OR  SREP  FLAG  FILE  TO  THE  ASSOCIATED 
GENERATE  PROCESS. 

EXECUTE  OUTGOING  CONTROL  PACKET  LAYER 


INCREMENT^ 

NONE 

NEW  VALUE  OF  R  (HIGHEST  SEQUENTIAL  DATA  MESSAGE  RECEIVED) 
USED  TO  UPDATE  THE  R^FILE  AND  TRIGGER  THE  SENDING  OF  AN 
ACK_PACKET. 

EXECUTE  INCOMING  CONTROL  PACKET  LAYER 
EXECUTE  DATA  PACKET  LAYER 


INITIAL  IZATION__COMPLETE 
NONE 

RESPONSE  TO  INITIALIZE_LINK  COMMAND 
EXECUTE  INCOMING  CONTROL  PACKETS  LAYER 


INITIALIZATION_ON_OTHERJ2n> 

NONE 
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VALDES  AND  MEANINGS 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 
NOTES: 


DATA  FLOW  NAME: 
ALIASES : 
COMPOSITION: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES: 


THE  OTHER  END  HAS  BEEN  INITIALIZED,  HALT  PROTOCOL. 
EXECDTE  ODTGOING  CONTROL  PACKET  LAYER 


INITIAL IZE_LINK 
NONE 

INITIALIZE  THE  PROTOCOL  AND  START  THE  DATA  LINK 
EXECDTE  ODTGOING  CONTROL  PACKET  LAYER 


INIT IAL_PACKET 
NONE 

INITIAL^ PACKET  =  2 {SYNC} 8  +  T SOH_PACKET~T 

I  DLE_PACKET  | 

I  enq_packet  | 

DECODE  AND  SYNC  INCOMING  BIT  STREAM  LAYER 


INVAL ID_BLKCK 1 
NONE 

FLAGS  AN  INCORRECTLY  RECEIVED  SGH/DLE  HEADER.  AN  NAK_ 
PACKET  IS  RETURNED  TO  THE  TRANSMITTER. 

FRAME  SECONDARY  INFORMATION  PACKETS  LAYER 
EXECDTE  INCOMING  CONTROL  PACKET  LAYER 


INVALID_BLKCK2 

NONE 

FLAGS  AN  INCORRECTLY  RECEIVED  DATA  FIELD.  AN  NAK_PACKET 
IS  GENERATED. 

FRAME  SECONDARY  INFORMATION  PACKETS  LAYER 
EXECDTE  INCOMING  CONTROL  PACKET  LAYER 


INVAL ID_BLKCK  3 
NONE 

FLAGS  AN  INCORRECTLY  RECEIVED  ENQ_HEADER.  AN  NAK_PACKET 
IS  GENERATED. 

FRAME  SECONDARY  INFORMATION  PACKETS  LAYER 
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EXECUTE  INCOMING  CONTROL  PACKET  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


INVALID_DATA_LENGTH 

NONE 

FLAGS  AN  INCORRECTLY  RECEIVED  DATA  LENGTH  FIELD.  AN  NAK_ 
PACKET  IS  GENERATED. 

FRAME  SECONDARY  INFORMATION  PACKETS  LAYER 
EXECUTE  INCOMING  CONTROL  PACKET  LAYER 
EXECUTE  DATA  PACKET  LAYER 


INVALID_DLE_PACKET 

NONE 

FLAGS  A  NON- SELECTED  TRANSMISSION  OWNERSHIP  CONTROL  BIT 
WHEN  IN  THE  MAINTENANCE  MODE 
FRAME  SECONDARY  INFORMATION  PACKETS  LAYER 
EXECUTE  INCOMING  CONTROL  PACKET  LAYER 


INVALID_PACRETS 

NONE 

FLAG  USED  TO  TRANSMIT  AN  NAK_PACKET  OBTAINED  FROM 
RECEPTION  OF  AN: 

1.  INVALID_BLKCK1 

2.  INVALIDJBLKCK2 

3 .  INVALID JBLKCK3 

4.  PACKET_NON_JLBUT 
EXECUTE  INCOMING  CONTROL  PACKET  LAYER 


INVAL ID_STACK_PACKET 
NONE 

A  FLAG  USED  TO  TRANSMITTER  TO  SEND  OUT  A  NAK_PACRET  SINCE 
THE  SELECT  BIT  WAS  NOT  SET  IN  THE  RECEIVED_STACK_PACKET 
RESULTING  IN  THE  RECEPTION  OF  A  BAD  STACK_PACKET. 

EXECUTE  INCOMING  CONTROL  PACKET  LAYER 


INVAL ID_STRT_?ACKET 
NONE 
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NOTES! 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


I  TRANSPORT 
I  TRANSPORT 

NOTES: 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 

NOTES: 


DATA  ELEMENT  NAME: 
ALIASES : 

VALUES  AND  MEANINGS 


NOTES: 


DATA  FLOW  NAME: 


A  FLAG  TO  THE  TRANSMITTER  TO  SEND  OUT  A  NARJPACKET  SINCE 
THE  SELECT  BIT  WAS  NOT  SET  IN  THE  RECEIVED_STRT_PACKET 
RESULTING  IN  THE  RECEPTION  OF  A  BAD  STRTJPACKET. 

EXECUTE  INCOMING  CONTROL  PACKET  LAYER 


LINK_AND— MODEHjCONTROL 
NONE 

link_and_nodem_control  =  Tdisable_linkT 

I  ENABLE_LINK  I 

START  REPLY  TIMER  LAYER 


LINK_DATA_ PACKET 
NONE 

LINK_DATA_PACKET  = 

PROTOCOL  +  BLKCK2  +  AD DR  +  BLKCK1  +  COUNT  +  SOH  +  FLAGS'! 
PROTOCOL  +  BLKCK2  +  AD DR  +  BLKCK1  +  COUNT  +  SOH  I 

FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 


LINX_PACKETS 

ABUTTED_PACKET 

SYNC_PACKET 

FOLLOWONJPACKET 

SEE  ALIASES 

EXECUTE  HDLC  PROTOCOL  AT  PRIMARY  NODE  LAYER 


LOCALLY_GENERATED_CRC_REMAINDER 

NONE 

A  SIXTEEN  BIT  SEQUENCE  THAT  IS  THE  REMAINDER  AFTER 
DIVISION  OF  THE  VALID_LENGTH_SOH/DLEJHEADER,  VALID_ 
LENGTH_DATA,  OR  VALID_LENGTH_ENQ_  HEADER  BY  THE  CRC 
POLYNOMIAL. 

FRAME  SECONDARY  INFORMATION  PACKETS  LAYER 


LONGJDATA_COUNT 
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e  ■  F  — u.-  *. . 


ALIASES: 

COMPOSITION: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS; 


NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


SHORTJDATA.COUNT 


LONG_DATA_COUNT  =  TRANSPORT  PROTOCOL  +  BLKCK2  +  AD DR  + 
SOH  +  COUNT 

FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 


MODEM_FAILURE 

NONE 

A  NOTIFICATION  FROM  THE  DRIVER  THAT  THE  MODEM/LINK  HAS 
FAILED. 

START  REPLY  TIMER  LAYER 


i 


MOP_PACKETS 

NONE 


MOP_PACKETS 


PARAME  TER_LOAD_WITH_TRAN  SFER^ADDRES  S 

MEMO  RY_LOAD_WITH_TRAN  SFERJUJDRES  S 

REQUEST_MEMORY_DUMP 

ENTEILMOP_MODE 

REQUEST_PROGRAM 

REQUEST  _JffiMO  RY_LOAD 

MOP  _MODE_RUNNING 

MEMO  RY  JDUMP_DA  TA 

LOOP_BACK_TEST 

MEMO  KY_LOAD_WITHOUT_TRAN  SFER^^AD  DRES  S 


EXECUTE  MAINTENANCE  PACKET  LAYER 
FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 


NAK^ PACKET 
RECEIVED_NAKJ?ACKET 

NAK_PACKET  =  ENQ  +  NARTYPE  +  REASON  +  FLAGS  +  RESP  + 
FILL  +  ADDR  +  BLKCK3 
EXECUTE  OUTGOING  CONTROL  PACKET  LAYER 
FRAME  PRIMARY  INFORMATION  PACKET  LAYER 


NAK_TRAN  SMIT_ FLAG 

SET_STARTUP 

RESYNC 

A  FLAG  USED  TO  SET  THE  CORRESPONDING  BIT  IN  THE  STARTUP. 
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NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 

NOTES: 


DATA  ELEMENT  NAME: 


FLAG_JILE. 

DECODE  AND  SYNC  INCOMING  BIT  STREAM  LAYER 
EXECUTE  INCOMING  CONTROL  PACKET  LAYER 


NAKTYPE 

NONE 

NAK  PACKET  TYPE  =  00000010 
ALL  LINK  LAYERS 


N=EVEN 

NONE 

WHEN  N  (COUNTER)  IS  AN  EVER  NUMBER  AND  THE  TRANSMITTER 
RECEIVES  A  VALID_STRT_PACKET,  THEN  RETURN  A  STACK^ PACKET. 
EXECUTE  OUTGOING  CONTROL  PACKET  LAYER 


N=ODD 

NONE 

WHEN  N  (COUNTER)  IS  A  ODD  NUMBER  AND  THE  TRANSMITTER 
RECEIVES  A  VALID_STRT_ PACKET ,  THEN  RETURN  A  STRT_PACKET. 
EXECUTE  OUTGOING  CONTROL  PACKET  LAYER 


NO_HEADERwDATAb_PACKET 

NONE 

NO_HEADERJ)ATA_PACRET  =  TRANSPORT  PACKET  +  BLKCK2  +  COUNT 
FRAMING  PRIMARY  INFORMATION  PACKETS  LAYER 


NOSYNC_PRIMARY_TO_SECONDARY_DATA*_PACKET 
COUNT ED_LINK_DATA_PACKET 
<  2  56 JLINK_PACKET 
RETRANSMITTED  JPACKETS 

SEE  ALIASES 

FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 


NUM 
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ALIASES: 

VALUES  AND  MEANINGS 


NONE 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


USED  TO  DENOTE  THE  NUMBER  OF  THIS  DATA  PACKET.  WHEN  USED 
WITH  REP_PACKET  IT  IS  THE  NUMBER  OF  THE  LAST  SEQUENTIALLY 
NUMBERED  DATA  PACKETS  SENT.  THIS  IS  COMPARED  AGAINST  THE 
NUMBER  OF  THE  LAST  SEQUENTIAL  PACKET  RECEIVED  AND  RESULTS 
IN  EITHER  AN  ACK  BEING  RETURNED  IF  THEY  AGREE  OR  A  NAK  IF 
THEY  DO  NOT. 

ALL  LINK  LAYERS 
START  REPLY  TIMER  LAYER 


PACKE  T_NON_ABUT 
NONE 

FLAG  INDICATING  THAT  THE  LAST  TWO  MESSAGES  RECEIVED  DID 
NOT  ABUT  AND  THE  TRANSMITTER  SHOULD  BE  NOTIFIED  TO 
RETRANSMIT. 

DECODE  AND  SYNC  INCOMING  BIT  STREAM  LAYER 
EXECUTE  HDLC  PROTOCOL  AT  PRIMARY  NODE  LAYER 
EXECUTE  INCOMING  CONTROL  PACKET  LAYER 
FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 


PERSISTENT_ERROR 

NONE 

AN  ERROR  HAS  OCCURRED  FROM  WHICH  RECOVERY  IS  NOT 
POSSIBLE. 

THIS  ERROR  IS:  1.  7  CONSECTATIVE  RESPONSES 

2.  TIMER  EXPIRATIONS 
START  REPLY  TIMER  LAYER 


PAD/STRT_PACKET 

NONE 

PAD / STRT_?ACKE  T  =  T I1I11111  +  STRT_PACKET~ 
I  STRT_PACKET  ! 

EXECUTE  OUTGOING  CONTROL  PACKET  LAYER 
FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 


PH YS I CAL_T 0_L I NK_PACKE TS 
NONE 
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NOTES: 


DATA  FLOW  NAME: 
ALIASES : 
COMPOSITION: 

NOTES: 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 


NOTES: 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 

NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


PHYS ICAL_TO_LINK— PACKETS  =  (2{SYNC}8)  +  I  SOH_PACKET  | 

I  DLE_PACKET  | 
I  ENQJPACKET  I 

DECODE  AND  SYNC  INCOMING  BIT  STREAM  LAYER 


PIGGYBACKED_LINK_J)ATA_PACKET 

NONE 

PIGGYBACKED JLINKJATA^PACKET  =  LINK_J)ATAJ>ACRET  +  RESP 
FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 


PRIMARY_INCOMING_BIT_STREAH_FROM_DRIVER 

PRIMARY_OOTGOING_BIT_STREAH_TO_DRIVER 

SECONDARY_ODTGOING_BIT_STREAM_TO_DRIVER 

SECONDARY_INCOMING_BIT_STREAMJFROM_DRIVER 

PRIMARY_INCOMING_BIT_STREAM_FROM JDRIVER  =  (11111111)  + 

(2{SYNC}8)  +  T”s0B_PACKEtT 
I  DLE_PACKET  I 
I  ENQ_PACKET  I 

DECODE  AND  SYNC  INCOMING  BIT  STREAM  LAYER 
OVERVIEW  LAYER 

EXECUTE  HDLC  PROTOCOL  AT  PRIMARY  NODE  LAYER 


primary_octgoing_bit_stream_to_driver 

PRIMARY_INCOMING_BIT_STREAM-FROM_DRIVER 

secondary_incoming_bit_stream_from_driver 

secondary_outgoing_bit_stream_to_driver 

SEE  ALIASES 
OVERVIEW  layer 

EXECUTE  HDLC  PROTOCOL  AT  PRIMARY  NODE  LAYER 
START  REPLY  TIMER  LAYER 


PRIMARY_TO_SECONDARY_DATAJPACKET 

NONE 

PRIMARY_TO_SECONDARY_DATAJPACKET  =  (2 (SYNC} 8)  ♦  LINR_ 
DATA_PACKET  +  RESP  +  HUM 
FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 


START  REPLY  TIMER  LAYER 

EXECUTE  HDLC  PROTOCOL  AT  PRIMARY  MODE  LAYER 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  FLOW  NAME: 
ALIASES : 


PRIMARY_TO_SECONDARY_CONTROL_PACKET 

NONE 

PRIMARY_TO_SECONDARY_CONTRGL_PACKET  =  M PAD/STRT ^PACKET 

I  NAKJPACKET 
I  STACK  ^PACKET 
I  ACKJPACKET 
I  REPJPACKET 

EXECUTE  HDLC  PROTOCOL  AT  PRIMARY  NODE  LAYER 


PRIMARY_TO_SECONDARYJKAINTENANCEJPACKET 

NONE 

PRIMARY_TO_SECONDARY_MAINTENANCE_PACKET  = 

I  TRANSMITJ)LE_PACKET~ 
I  MOP_PACKETS  | 

EXECUTE  HDLC  PROTOCOL  AT  PRIMARY  NODE  LAYER 


QSYNC 

NONE 

QUICK  SYNC  FLAG,  USED  TO  NOTIFY  THE  RECEIVER  THAT  THE 
NEXT  PACKET  WILL  NOT  ABUT  THIS  PACKET,  AND 
RESYNCHRONIZATION  SHOULD  FOLLOW  THIS  PACKET. 

FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 


QSYNC_DATA^PACKET 

NONE 

QSYNC_DATA_PACKET  =  TRANSPORT  PROTOCOL  +  BLKCK2  +  ADDR  + 

COUNT  +  SOH  +  FLAGS 
FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 


QSYNC_ENQ/DLE_PACKET 

ENQ/DLE_SYNC_PACKET 
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COMPOSITION 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


SEE  ALIASES 

FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 


RCVR 

NONE 

CONTROL  PACKET  RECEIVER  FIELD.  USED  TO  PASS  INFORMATION 
FROM  THE  DATA  PACKET  RECEIVER  TO  THE  DATA  PACKET  SENDER. 
ALL  LINK  LAYERS 


REASON 

NONE 

NAK  ERROR  REASONS 

1.  ERROR  DUE  TO  TRANSMISSION  MEDIUM 
000001  =  HEADER  BLOCK  CHECK  ERROR 
000010  =  DATA  FIELD  BLOCK  CHECK  ERROR 
000011  =  REP  RESPONSE 

2.  ERROR  DUE  TO  COMPUTERS/ INTERFACE 
001000  =  BUFFER  TEMPORARILY  UNAVAILABLE 
001001  =  RECEIVE  OVERRUN 

010000  =  PACKET  TOO  LONG 
010001  =  PACKET  HEADER  FORMAT  ERROR 
ALL  LINK  LAYERS 


RECEIVED  JVCKJPACKET 
ACK_PACKET 

SEE  ALIASES 

EXECUTE  INCOMING  CONTROL  PACKET  LAYER 

EXECUTE  DATA  PACKET  LAYER 

EXECUTE  HDLC  PROTOCOL  AT  PRIMARY  NODE  LAYER 


RECEIVED _NAK_PACKET 
NAK_PACKET 

SEE  ALIASES 

EXECUTE  INCOMING  CONTROL  PACKET  LAYER 
EXECUTE  DATA  PACKET  LAYER 
FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 
EXECUTE  HDLC  PROTOCOL  AT  PRIMARY  NODE  LAYER 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES : 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 


DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


RECEIVED  _PRI MARY_NODE_TRAN  SPORT_PACKET 
RECE IVED_SECONDARY_NODE_TRAN  SPORT_PACKET 

SEE  ALIASES 
OVERVIEW  LAYER 


RECE  IVED_REP_PACRET 
REP_PACKET 

SEE  ALIASES 

EXECUTE  INCOMING  CONTROL  PACKET  LAYER 


RECEIVED_SECONDARY_NODE_TRANSPORT_PACKET 

RECEIVED_PRIMARY_NODE_TRANSPORT_PACKET 

RECEIVED_SECONDARY_NODE_TRANSPORT_PACKET  =  TRANSPORTJTO. 

LINK_DATA_PACRET 

OVERVIEW  LAYER 


RECEIVED_STACKJPACKET 

STACK_PACRET 

VALID_STACK_PACKET 

SEE  ALIASES 

EXECUTE  INCOMING  CONTROL  PACKET  LAYER 
START  REPLY  TIMER  LAYER 


RECE  IVED_STRT_PACKE  T 

STRT_PACKET 

VALID_STRTJPACKET 

SEE  ALIASES 

EXECUTE  INCOMING  CONTROL  PACKET  LAYER 
START  REPLY  TIMER  LAYER 


RECE IVE_PACKET 
NONE 

TRANSPORT  PROTOCOL  SUPPLIES  A  POOL  OF  BUFFERS  TO  THE  LINK 
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PROTOCOL • 

NOTES:  FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 


DATA  FLOW  NAME:  REP_PACKET 

ALIASES:  RECEIVED_REP_PACKET 

COMPOSITION: 

REP_PACKET  =  ENQ  +  REPTYPE  +  REPSUB  +  FLAGS  +  FILL  + 
NUM  +  ADDR  +  BLKCK3 

NOTES:  FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 

EXECUTE  OUTGOING  CONTROL  PACKET  LAYER 


DATA  ELEMENT  NAME:  REPSUB 

ALIASES:  NONE 

VALUES  AND  MEANINGS: 

REP  SUBTYPE  =  00000000 
NOTES:  ALL  .INK  LAYERS 


DATA  ELEMENT  NAME:  REPTYPE 

ALIASES:  NONE 

VALUES  AND  MEANINGS: 

REP  PACKET  TYPE  =  0000001 1 
NOTES:  ALL  LINK  LAYERS 


DATA  ELEMENT  NAME:  RESET.SIGNAL 

AL/ASES:  NONE 

VALUES  AND  MEANINGS: 

A  FLAG  TO  THE  TIMER  TO  RESET  SINCE  A  POSITIVE  ACKNOWLEDGE 
HAS  BEEN  RECEIVED. 

NOTES:  START  REPLY  TIMER  LAYER 


DATA  ELEMENT  NAME:  RESET_STARTUP 
ALIASES:  NONE 

VALUES  AND  MEANINGS: 

A  FLAG  TO  THE  STARTUP_FLAG_FILE  TO  CLEAR  THIS  FILE. 
NOTES:  DECODE  AND  SYNC  INCOMING  BIT  STREAM  LAYER 


DATA  ELEMENT  NAME:  RESP 
ALIASES:  NONE 
VALUES  AND  MEANINGS: 
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NOTES : 

DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 
NOTES: 

DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 

DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 

DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 


USED  TO  ACKNOWLEDGE  CORRECTLY  RECEIVED  PACKETS  (THE 
PIGGYBACKED  ACK) .  THE  NUMBER  REPRESENTS  THE  LAST 
CONSECUTIVE  CORRECTLY  RECEIVED  PACKET  RECEIVED  FROM  THE 
ADDRESSED  NODE  BY  THE  NODE  TRANSMITTING  THIS  PACKET.  IT 
IMPLYS  THAT  ALL  UNACKNOWLEDGED  PACKETS  BETWEEN  THE  ONE 
ACKNOWLEDGED  IN  THE  LAST  RESP  FIELD  RECEIVED  AND  THE  ONE 
ACKNOWLEDGED  BY  THIS  RESP  FIELD  (MOD  256) .  HAVE  BEEN 
RECEIVED  CORRECTLY.  WHEN  USED  IN  A  NAK_PACKET.  USUALLY 
IMPLYS  SOME  ERROR  IN  A  PACKET  WITH  NUMBER  RESP  +  1  OR 
BEYOND. 

ALL  LINK  LAYERS 


RESYNC 

NAK_TRAN SMIT_FLAG 
SET_STARTUP 

SEE  ALIASES 

DECODE  AND  SYNC  INCOMING  BIT  STREAM  LAYER 


RETRAN  SMITTED_PACKETS 
COUNTED_LINK_DATA_PACKET 
<  256JLINKJPACKET 

NOSYNC_PRIMARY_TO_SECONDARY_DATA_PACKET 
SEE  ALIASES 

FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 


SECOND ARY_INCOMING_BIT_STREAM_FROM_DRIVER 
PRIMARY_INCOMING_BIT_STREAM_FROM_DRIVER 
PRIMARY_OUTGOING_BIT_STREAM_TO_DRIVER 
SECOND ARY_OUTGOING_BIT_STREAM_TO_DRIVER 

SEE  ALIASES: 

OVERVIEW  LAYER 


SECONDARY_OUTGOING_BIT_STREAM_TO_DRIVER 

PRIMARY_INCOMING_BIT_STREAM_FROM_DRIVER 

PRIMARY_OUTGOING_BIT_STREAM_TO_DRIVER 

SECONDARY_INCOMING_BIT_STREAM_FROM_DRIVER 

SEE  ALIASES 
OVERVIEW  LAYER 
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DATA  ELEMENT  NAME:  SET 
ALIASES :  NONE 

VALDES  AND  MEANINGS: 

A  FLAG  TO  SET  COUNTERS,  SNAR  FLAG  FILE  OR  SACK  FLAG  FILE. 
NOTES:  EXECUTE  INCOMING  CONTROL  PACKET  LAYER 


DATA  ELEMENT  NAME:  SET_STARTUP 
ALIASES:  NAK_TRANSMIT_FLAG 

RESYNC 

VALUES  AND  MEANINGS: 

SEE  ALIASES 

NOTES:  DECODE  AND  SYNC  INCOMING  BIT  STREAM  LAYER 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


SHORT_DATA__COUNT 
LON  G_DATA_COU  NT 

SEE  ALIASES 

FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 


DATA  ELEMENT  NAME:  SNDR 
ALIASES:  NONE 

VALUES  AND  MEANINGS: 

CONTROL  PACKAT  SENDER  FIELD.  USED  TO  PASS  INFORMATION 
FROM  THE  DATA  PACKET  SENDER  TO  THE  DATA  PACKET  RECEIVER. 
N0TES:  ALL  LINK  LAYERS 


DATA  ELEMENT  NAME:  SOH 
ALIASES :  NONE 
VALUES  AND  MEANINGS: 

THE  NUMBERED  DATA  MESSAGE  IDENTIFIER  =  10000001 
NOTES :  ALL  LINK  LAYERS 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


SOH_PACKET 

VALID_SOH_PACKET 

SOH_PACKET  =  SOH  +  COUNT  +  FLAGS  +  RESP  +  NUM  +  AD DR  + 
BLKCK1  +  DATA  +  BLKCK2 

DECODE  AND  SYNC  INCOMING  BIT  STREAM  LAYER 
FRAME  SECONDARY  INFORMATION  PACKETS  LAYER 
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DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES : 

VALDES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES : 

VALDES  AND  MEANINGS: 
NOTES: 


STACK_PACKET 

VAL ID_STACK_?ACKET 

RECEIVED_STACK_PACKET 

STACK_PACKET  =  ENQ  +  STCKTYPE  +  STCKSUB  +  FLAGS  +  FILL  + 
FILL  +  AD DR  +  BLKCK3 
EXECDTE  ODTGOING  CONTROL  PACKET  LAYER 
FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 


START 

NONE 

A  FLAG  TO  THE  LOAD  AND  DELETE  MEMORY  PROCESS  TO  TRIGGER 
THE  SENDING  OF  RETRANSMITTED_PACKETS » 

FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 


STARTUP 

NONE 

A  FLAG  TO  THE  “CHECK  FOR  STARTOP"  PROCESS  TO  SET  OR  CLEAR 
THE  STARTUP  BIT. 

DECODE  AND  SYNC  INCOMING  BIT  STREAM  LAYER 


STCKSUB 

NONE 

STACK  SUBTYPE  =  00000000 
ALL  LINK  LAYERS 


STCKTYPE 

NONE 

STACK  PACKET  TYPE  =  00000111 
ALL  LINK  LAYERS 


DATA  ELEMENT  NAME:  STOP_LINK 

ALIASES:  NONE 

VALDES  AND  MEANINGS: 
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NOTES: 


HALT  THE  PROTOCOL 
START  REPLY  TIMER  LAYER 


DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 


NOTES: 


STRTJPACKET 

VALID_STRT_PACRET 

RECEIVED_.STRT_PACKET 

STRT_PACKET  =  ENQ  +  STRTTYPE  +  STRTSOB  +  FLAGS  +  FILL  + 
PILL  +  ADDR  BLKCK3 

EXECUTE  OUTGOING  CONTROL  PACKET  LAYER 
FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 


DATA  ELEMENT  NAME:  STRTSUB 
ALIASES:  NONE 

VALUES  AND  MEANINGS: 

STRT  SUBTYPE  =  00000000 
NOTES!  ALL  LINK  LAYERS 


DATA  ELEMENT  NAME:  STRTTYPE 
ALIASES :  NONE 

VALUES  AND  MEANINGS: 

STRT  PACKET  TYPE  =  00000110 
N0TES5  ALL  LINK  LAYERS 


DATA  FLOW  NAME:  SUBTYPE 

ALIASES :  NONE 

COMPOSITION: 


NOTES: 


ALL^NK^YERS81785  +  (REPSDB)  +  ( STRTSUB)  +  (STCKSUB)] 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


SYNC 

NONE 

SYNCHRONIZATION  BYTE,  THE  OCTET  10010110 
OVERVIEW  LAYER 


DATA  FLOW  NAME: 
ALIASES: 


SYNC_PACKET 
F  OL  LOWON_PACKE  T 
ABUTTED_PACKET 
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COMPOSITION 


LINK-JACKETS 


NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALDES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES : 

VALDES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 


SEE  ALIASES 

DECODE  AND  SYNC  INCOMING  BIT  STREAM  LAYER 


TIMEODT 

NONE 

TIMEODT  =  INCREMENT  ERROR  CODNTER  +  |  TIMEOUT_J)ATA 

!  TIMEOOT_STRT 
I  TIMEOOT_STACK 


START  REPLY  TIMER  LAYER 


TIMEOOT-DATA 

NONE 

AN  ACKNOWLEDGEMENT  TO  DATA  PACKET  IS  HELD  DP  AND  RESDLTS 
IN  THE  REPLY  TIMER  EXPIRATION  CADSING  A  TIMEODT  SIGNAL 
TO  TRIGGER  THE  SENDING  OF  A  REP_PACKET. 

START  REPLY  TIMER  LAYER. 


TIMEODT_STACK 

NONE 

AN  ACKNOWLEDGEMENT  TO  A  STACK_PACKET  IS  HELD  DP  AND 
RESDLTS  IN  THE  REPLY  TIMER  EXPIRATION  CADSING  A  TIMEODT 
SIGNAL  TO  TRIGGER  THE  SENDING  OF  A  STACK-JACKET . 

START  REPLY  TIMER  LAYER 

EXECDTE  ODTGOING  CONTROL  PACKET  LAYER 


TIMEOOT_STRT 

NONE 

AN  ACKNOWLEDGEMENT  TO  A  START  PACKET  IS  HELD  DP  AND 
RESDLTS  IN  THE  REPLY  TIMER  EXPIRATION  CADSING  A  TIMEODT 
SIGNAL  TO  TRIGGER  THE  RESENDING  OF  A  STRT_PACKET. 

START  REPLY  TIMER  LAYER 

EXECDTE  ODTGOING  CONTROL  PACKET  LAYER 


TRAN  SMIT—COMPLETE 
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ALIASES: 

VALUES  AND  MEANINGS: 


NONE 


"T  ' 


\ 

< 

NOTES: 


A  NOTIFICATION  TO  THE  LINK  PROTOCOL  ONCE  TOE  DRIVER  HAS 
COMPLETED  A  PREVIOUS  TRANSMIT_A_BLOCK  COMMAND 
START  REPLY  TIMER  LAYER 


DATA  FLOW  NAME: 
ALIASES: 


TRAN  SMIT_PLE_PACKET 

DLEJ?ACKET 

VALID  J)LE_?ACKET 


COMPOSITION: 

NOTES: 


SEE  ALIASES 

EXECUTE  MAINTENANCE  PACKET  LAYER 

hbtuadv  tmtorMATION  PACKETS  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


TRANSIENT_ERRORjraRESHOLD_COUNTEIL_OVERFLOW 

NONE 


ERRORJIHRESHOLD  COUNTER  OVERFLOW  DUE  TO 

1.  NAKS  RECEIVED 

2.  ERRORS  THAT  CAUSE  NAKS  TO  BE  SENT 
THIS  COMMAND  AUTOMATICLY  CLEARS  THE  TRESHOLD_COUNIER 
WHEN  THE  NUMBER  OF  ERRORS  RECORDED  EQUALS  7 . 

EXECUTE  INCOMING  CONTROL  PACKET  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


TRANSMIT_A_  BLOCK 
NONE 

PASS  A  BLOCK  TO  THE  DRIVER  FOR  TRANSMISSION. 
START  REPLY  TIMER  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


TRANSMIT_PACKET 

NONE 

GIVE  A  PACKET  TO  LINK  PROTOCOL  FOR  TRANSMISSION. 
FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


TRANSMITTED_PRIMARY_NODE_TRANSPORT_PACKET 
TRANSMITTED^ SECONDARY_NODE_TRANSPORT_PACKET 

SEE  ALIASES 

EXECUTE  DATA  PACKET  LAYER 
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DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS 
NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 

NOTES: 


DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 


OVERVIEW  LAYER 

EXECUTE  HDLC  PROTOCOL  AT  PRIMARY  NODE  LAYER 


TRAN SMITTED_SECONDARY_NODE_,TRAN SPORT  J?ACKET 
TRAN  SMITTED_PRI MARY_NODE_TRAN  SPO  RT_PACKET 

TRAN SMITTED_SECONDARY_NODE_TRAN SPORT  J?ACKET 

OVERVIEW  LAYER 


TRAN  SPORT_TO_LINK_PATA— PACKET 
NONE 

ANY  TRANSPORT  PACKET 

EXECUTE  HDLC  PROTOCOL  AT  PRIMARY  NODE  LAYER 
FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 


TYPE 

NONE 

TYPE  =  TaTCKTYPE~ 
I  STRTTYPE  | 
I  REPTYPE  I 
I  NAKJTYPE  I 
(  ACKJTYPE  I 

ALL  LINK  LAYERS 


VAL  ID_CRC_ENQ_PACKET 
ENQ_PACKET 
VALID_ENQ_PACKET 
validjlength_enq_header 


SEE  ALIASES 

FRAME  SECONDARY  INFORMATION  PACKETS  LAYER 


VALID_CRC_SOH/DLE_PACKET 
VALID_LENGTH_SOH/DLE_HEADER 
VALID_SOH/DLE_HEADER 
VAL  ID_LENG  THJ5ATA 


VALID_SOH_ 

PACKET 
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VALID_CRC_CRC/DLE_PACKET  = 


I  SOB 
I  DLE 

NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES : 


DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 

DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 
NOTES : 

DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 

DATA  FLOW  NAME: 
ALIASES: 


COUNT  +  FLAGS  +  RESP  +  NUM  +  AD DR  +  BLKCK1  +  DATA  + 
COUNT  +  FLAGS  +  FILL  +  FILL  +  ADDR  +  BLKCR1  +  DATA 

FRAME  SECONDARY  INFORMATION  PACKETS  LAYER 


VALID_DLE_PACKET 

DLE_PACKET 

SEE  ALIASES 

FRAME  SECONDARY  INFORMATION  PACKETS  LAYER 
EXECUTE  DATA  PACKET  LAYER 


VALID_ENQ_PACKET 

ENQ_PACKET 

VALID_CRC_ENQ_PACKET 

VALID-LENGTH_ENQ_HEADER 

SEE  ALIASES 

FRAME  SECONDARY  INFORMATION  PACKETS  LAYER 
EXECUTE  INCOMING  CONTROL  PACKET  LAYER 


VALID_LENGTH_DATA 
VALID_CRC__SOH/DLE_PACKET 
VALID_LENGTH_SOH/DLE_PACKET 
VAL ID_S  OH / DL  E_HEADER 

SEE  ALIASES 

FRAME  SECONDARY  INFORMATION  PACKETS  LAYER 


VALID_LENGTH_ENQ_READER 

ENQ_PACKET 

VALID_ENQ_PACKET 

VALID_CRC_ENQ_PACKET 

SEE  ALIASES 

FRAME  SECONDARY  INFORMATION  PACKETS  LAYER 


VALID_LENGTR_SOH/DLE_READER 

VALID_CRC_SOH/DLE_HEADER 


BLKCK2 
+  BLKCK2 
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COMPOSITION: 

NOTES: 

DATA  FLOW  NAME: 
ALIASES: 


COMPOSITION: 

NOTES: 


DATA  FLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 

DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION : 
NOTES: 

DATA  FLOW  NAME; 
ALIASES: 

COMPOSITION: 

NOTES: 

DATA  FLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 


VAL ID_LENGTHJDATA 
SEE  ALIASES 

FRAME  SECONDARY  INFORMATION  PACKETS  LAYER 


VALID_SOH/DLE_HEADER 
VALID_CRC_S  OH/ DLEJPACKET 
VALID_LENGTHJDATA 
VALID_LENGTH_SOH/DLE_HEADER 
SEE  ALIASES 

FRAME  SECONDARY  INFORMATION  PACKETS  LAYER 


VALID_SOH_PACKET 

SOH_PACKET 

SEE  ALIASES 

FRAME  SECONDARY  INFORMATION  PACKETS  LAYER 
EXECUTE  DATA  PACKET  LAYER 


VALID_STACK_PACKET 

STACKJPACKET 

RECE  IVED__STACK_PACKET 

SEE  ALIASES 

EXECUTE  INCOMING  CONTROL  PACKET  LAYER 


VALID_STRT_PACKET 

STRT_PACKET 

RECEIVED_STRT_PACKET 

SEE  ALIASES 

EXECUTE  INCOMING  CONTROL  PACKET  LAYER 
EXECUTE  OUTGOING  CONTROL  PACKET  LAYER 


<  2  56  _I>INK_PACKET 
COUNT ED_LINK_DATA_PACKET 
RETRANSMITTED JPACKETS 

NOSYNC  _PRIMARY_TO_SECONDARY_DATA_PACKET 
SEE  ALIASES 

FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 
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FILE  OR  DATABASE  NAME! 
ALIASES: 

COMPOSITION! 


im.F.  nr.riKlTIQMS  111 
AFFILE 
NONE 


THE  NUMBER  OF  THE  HIGHEST  SEQU0TTIAL  DATA  MESSAGE  THAT 
HAS  BEEN  ACKNOWUDGED  TO  THIS  JTATWN^RECEIVED^IN 

RESP  FIELD  OF  DATA_PACKETS . 


BAPT'B'TS  . 


ORGANIZATION! 

NOTES; 


ISmE°HDLC  PROTOCOL  AT  PRIMARY  NODE  LAYER 

EXECUTE  DATA  PACKET  LAYER 

FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 

START  REPLY  TIMER  LAYER 


FILE  OR  DATABASE  NAME: 
ALIASES: 

COMPOSITION: 

ORGANIZATION: 

NOTES: 


HOLDJTABLE 

NONE 


HOLDJTABLE  =  LlNK_PATA_PACKET 
m^PRIMARY^NFORMATION  PACKETS  LAYER 


FILE  OR  DATABASE  NAME: 
ALIASES: 

COMPOSITION: 


LINKJTOJPHYSICALjCOMMANDJTABLE 

NONE 


.INK  TO  PHYSICAL-COMMAND JT ABLE  = 

(LINK _AND_MODEM_CONTROL)  + 

m _ _  a  nv  f\s*rr  > 


ORGANIZATION: 

NOTES: 


20-BIT  TABLE 

START  REPLY  TIMER  LAYER 


FILE  OR  DATABASE  NAME: 
ALIASES: 

COMPOSITION: 


ORGANIZATION: 

NOTES: 


LINK JTO JTRAN  SPORT_COMMAND_TABLE 
NONE 

L  INK_TO_TRAN  SPO  RT_COMMAND JTABLE  =  (  PERSISTENT_ERROR)  + 
( TRANSIENT  JERRORJTHRESHOLD_COUNTER_OVERFLOW  )  + 
( INITIAL IZATION_ON_OTHER_END)  + 

( INITIAL IZATION_COMPLETE) 

4- BIT  TABLE 

EXECUTE  INCOMING  CONTROL  PACKET  LAYER 
EXECUTE  OUTGOING  CONTROL  PACKET  LAYER 
START  REPLY  TIMER  LAYER 


FILE  OR  DATABASE  NAME:  MEMORY 
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ALIASES: 

COMPOSITION: 


ORGANIZATION: 

NOTES: 


NONE 

STANDARD  COMPUTER  MEMORY.  ALL  DATA  PACKETS  SENT  ARE 
RECORDED  IN  MEMORY  AND  WHEN  A  VALID  ACKNOWLEDGE  IS 
RECEIVED  THEY  ARE  DELETED. 

VARIABLE  LENGTH  8-BIT-BYTE  WORDS 
FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 


FILE  OR  DATABASE  NAME: 
ALIASES: 

COMPOSITION: 


ORGANIZATION: 

NOTES: 


PHYS  ical_to_link_command_table 
NONE 

PHYSICAL  TO_LINK_COMMAND_TABLE  =  (TRANSMIT_COMPLETE)  + 

(MODEM_FAILORE) 

2- BIT  TABLE 

START  REPLY  TIMER  LAYER 


FILE  OR  DATABASE  NAME: 
ALIASES: 

COMPOSITION: 


ORGANIZATION: 

NOTES: 


R_FILE 

NONE 

THE  NUMBER  OF  THE  HIGHEST  SEQUENTIAL  DATA  PACKET 
RECEIVED  AT  THIS  STATION.  SENT  IN  THE  RESP  FIELD 
OF  DATA^. PACKETS ,  ACK_PACKETS,  AND  NAK_PACKETS  AS 
ACKNOWLEDGEMENT  TO  THE  OTHER  STATION. 

SINGLE  OCTET 

EXECUTE  HDLC  PROTOCOL  AT  PRIMARY  NODE  LAYER 
EXECUTE  INCOMING  CONTROL  PACKET  LAYER 
EXECUTE  DATA  PACKET  LAYER 
FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 


FILE  OR  DATABASE  NAME: 
ALIASES: 

COMPOSITION: 


ORGANIZATION: 

NOTES: 


SACK 

NONE 

THIS  FLAG  IS  SET  WHEN  EITHER  THE  R-FILE  IS  INCREMENTED 
MEANING  A  NEW  SEQUENTIAL  DATA  PACKET  HAS  BEEN  RECEIVED 
WHICH  REQUIRES  AN  ACK  REPLY.  THE  SACK  FLAG  IS  CLEARED 
WHEN  SENDING  EITHER  A  DATA  PACKET  WITH  THE  LATEST  RESP 
FIELD  INFORMATION,  OR  AN  ACK  WITH  THE  LATEST  RESP 
FIELD  INFORMATION. 

SINGLE-BIT  VARIABLE 

EXECUTE  HDLC  PROTOCOL  AT  PRIMARY  NODE  LAYER 
EXECUTE  INCOMING  CONTROL  PACKET  LAYER 
EXECUTE  OUTGOING  CONTROL  PACKET  LAYER 
FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 
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FILE  OR  DATABASE  NAME: 
ALIASES: 

COMPOSITION: 


ORGANIZATION: 


FILE  OR  DATABASE  NAME: 
ALIASES: 

COMPOSITION: 


ORGANIZATION: 
NOTES : 


FILE  OR  DATABASE  NAME: 
ALIASES: 

COMPOSITION: 


ORGANZATION: 

NOTES: 


FILE  OR  DATABASE  NAME: 
ALIASES: 

COMPOSITION: 


ORGANZATION: 

NOTES: 


SNAK 

NONE 


- T  ,  f,  TC  epT  WHEN  A  RECEIVE  ERROR  OCCURS  THAT 

ilFC0»N?EA5DtT?«f ET 

ASNAK  REASON  VARIALBE  IS  SET  IN  THE  FILE. 


SREP 

NONE 

*  tjttplY  TIMER  EXPIRES  IN  THE 
S^StItE  AND  A  REP  SHOULD  BE  SENT.  IT  IS  CLEARED 
WHEN  AN  REP .PACKET  IS  SENT. 

SINGLE- BIT  VARIABLE 

EXECUTE  HDLC  PROTOCOL  AT  PRIMARY  NODE  LAYER 
EXECUTE  OUTGOING  CONTROL  PACKET  LAYER 

_ _ -  t  4WO 


STARTDP_FLAG_FILE 

NONE 


A  FLAG  THAT  IS  SET  WHEN 

1.  STARTUP-PAD  SEQUENCE  IDENTIFIED 

2.  TO  LOCATE  THE  NEXT  PACKET  AFTER  A  NAK_ 

PACKET  IS  SENT. 

3.  TO  LOCATE  THE  NEXT  PACKET  AFTER  A  QSYNC_ 

PACKET  IS  SENT. 

THE  FLAG  IS  CLEARED  ON  THE  RECEPTION  OF  A  NORMAL 
(NO_PAD  SEQUENCE)  PACKET. 

SINGLE-BIT  VARIABLE 

DECODE  AND  SYNC  INCOMING  BIT  STREAM  LAYER 


T_FILE 

NONE 


THE  NUMBER  OF  THE  NEXT  DATA_PACKET  TO  BE  TRANSMITTED. 
WHEN  SENDING  NEW  DATA^PACKETS .  T  WILL  HAVE  THE  VALUE 
V  +  1.  WHEN  RETRANSMITTING,  T  WILL  BE  SET  BACK  TO 
A  +  1  AND  WILL  ADVANCE  TO  V  +  1 . 

SINGLE  OCTET 

EXECUTE  HDLC  PROTOCOL  AT  PRIMARY  NODE  LAYER 
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FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 


FILE  OR  DATABASE 
ALIASES : 
COMPOSITION: 


ORGAIZATION: 

NOTES: 


FILE  OR  DATABASE 

ALIASES: 

COMPOSITION: 


ORGANIZATION: 

NOTES: 


NAME :  TRAN  SPORT_TO_LINK_COMMAND_TABLE 
NONE 

TRANSPORT_TO_LINK_COMMAND_TABLE  =  (STOPJLINK)  + 

(INITIALIZE_LINK)  +  ( RECEIVE_PACKET)  + 
( TRAN  SMIT_ P ACKET )  + 

( ENTERJMAINTENACE_MODE ) 

5-BIT  TABLE 

START  REPLY  TIMER  LAYER 
EXECUTE  OUTGOING  CONTROL  PACKET  LAYER 
EXECUTE  MAINTENANCE  PACKET  LAYER 
FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 


NAME :  V_FILE 
NONE 

THE  NUMBER  OF  THE  HIGHEST  SEQUENTIAL  DATAJPACKET 
TRANSMITTED  BY  THIS  STATION.  SENT  IN  THE  NUM  FIELD 
OF  REP_PACRETS.  V  IS  THE  NUMBER  ASSIGNED  TO  THE  LAST 
USER  TRANSMIT  REQUEST  WHICH  HAS  BEEN  TRANSMITTED 
(SENT  IN  THE  NUM  FIELD  OF  THAT  DAT  PACKET). 

SINGLE  OCTET 

EXECUTE  HDLC  PROTOCOL  AT  PRIMARY  NODE  LAYER 
EXECUTE  OUTGOING  CONTROL  PACKET  LAYER 
FRAME  PRIMARY  INFORMATION  PACKETS  LAYER 
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ppnrvsfi  SPECTFT C*T™NS  (Ll 

PROCESS  NAME:  CSECR  FOR  AND  REMOVE  PAD  SEQOENCE 

PROCESS  NUMBER:  1.1.1 

PROCESS  DESCRIPTION: 

IF  111111111001011010010110  is  encountered  then 
Delete  the  11111111 

Output  a  SET_STARTUP_FLAG 
Output  next  consecutive  bytes 
ELSE  output  the  next  consecutive  bytes 


PROCESS  NAME--  fj“  F°R  ST“W? 

PROCESS  NUMBER:  1.1.2 

PROCESS  DESCRIPTION: 

IF  STARTUP  flag  set  then 

Output  next  packet  as  INITIAL_PACKEl 

ae8et  STARTUP  f0LLOWON_PACKET 

ELSE  output  next  packet  as 


LOCATE  TWO  CONSECUTIVE  SYNC  BYTES 

1.1.3 


PROCESS  NAME:  LOCATE  TWU 

PROCESS  NUMBER:  1.1.3 

PROCESS  DESCRIPTION: 

STRIP  off  all  sync  bytes 

Output  remaining  bytes  as  SYNC_PACKETS 


PROCESS  NAME:  DECODE  PACKET  READER 

PROCESS  NUMBER:  1.1.4 

PROCESS  DESCRIPTION: 

IF  first  byte  =  10000001  then 

Output  ABUTTEDJPACKET  (SOH_PACKET) 
ELSEIF  first  bytv*  =  00000101  then 

Output  ABUTTED_PACKET  (ENQ_PACXET) 
ELSEIF  first  byte  s  10010000  then 

Output  ABUTTED_PACKET  (DLE_PACKET) 
ELSE  output  PACKET_NONJtBUT 


PROCESS  NAME:  CHECK  FOR  QSYNC 

PROCESS  NUMBER:  1.1.5 

PROCESS  DESCRIPTION: 

IF  23rd  bit  set  then 

Output  RESYNC  to  set  STARTUP_FLAG_FILE 
Output  SOH.  DLE,  or  ENQ_PACKET 
ELSE  output  SOH.  DLE,  ox  ENCj_PACKET 


PROCESS  NAME:  CHECK  HEADER  LENGTH 

PROCESS  NUMBER:  1.2.1 

PROCESS  DESCRIPTION: 

IF  SOH_PACKET  or  DLE_PACKET  headers  are  less  than  48  bits  long  then 
Output  HEADEIL.FORMAT_ERROR 
ELSE  output  VALID_LENGTH_SOH/DLE_HEADER 


PROCESS  NAME:  CHECK  BLKCK1 

PROCESS  NUMBER:  1.2.2 

PROCESS  DESCRIPTION: 

IF  the  BLKCK1  and  the  LOCALLY _GENERATED_CRC_REMAINDER  are  equal  then 
Output  VALID_LENGTH_SOH/DLE_HEADER  as  a  VALID_SOH/DLE_HEADER 
ELSE  output  as  a  INVALID_BLKCK1 


PROCESS  NAME:  CHECK  DATA  LENGTH  (COUNT) 

PROCESS  NUMBER:  1.2.3 

PROCESS  DESCRIPTION: 

IF  SOH_PACKET  or  DLE_PACKET  data  fields  are  less  than  the  value  recorded  in 
the  COUNT  field  then 

Output  V AL ID_S OH/ DLE_HE ADER  as  an  INVALID_DATA_LENGTH 
ELSE  output  as  a  INVAL ID_LENGTH_DATA 


PROCESS  NAME:  CHECK  BLKCK2 

PROCESS  NUMBER:  1.2.4 

PROCESS  DESCRIPTION: 

IF  the  BLKCK2  and  the  LOCALLY_GENERATED_CRC_REMAINDER  are  equal  then 
Output  VAL ID_LENGTH_DATA  as  a  VALID_CRC_SOH/DLE_PACKET 
ELSE  output  as  a  INVALID_BLKCK2 


PROCESS  NAME:  CHECK  ENQ  HEADER  LENGTH 

PROCESS  NUMBER:  1.2.5 

PROCESS  DESCRIPTION: 

IF  ENQ_PACKET  header  is  less  than  48  bits  long  then 
Output  READER_FORMAT_ERROR 
ELSE  output  as  VALID_LENGTH_ENQ_HEADER 


PROCESS  NAME:  CHECK  BLKCK3 

PROCESS  NUMBER:  1.2.6 

PROCESS  DESCRIPTION: 
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IF  the  BLKCK3  and  the  LOCALLY_GENERATED_CRC_REMAINDER  are  equal  then 
Output  the  VALir_LEKGTH_ENQ_HEADER  as  VALID_CRC_ENQ_PACKET 
ELSE  output  INVALIDJBLKCK3 


PROCESS  NAME:  GENERATE  CRC  REMAINDER 

PROCESS  NUMBER:  1.2.7 

PROCESS  DESCRIPTION:  .  ,  , 

APPEND  16  zeros  after  the  header  or  data  protion  of  the  packet  ( VALID_LENOTH_ 

SOH/DLE_READER,  VALID_LENGTH_DATA,  VALID_LENGTH_ENQ_HEADER) 

TAKE  the  string  of  bits  constructed  and  treat  each  bit  as  the  coefficient 
of  a  term  of  a  ploynomlal  with  the  LSB  of  the  first  byte  being  the 

coefficient  of  the  highest  order  polynomial  term.  The  highest  order 
term  is  A  *  X  **  63  for  a  header  block  and  A  *  X.**  (8  *  (count)  + 
15)  for  a  data  block  where  A  is  the  least  significant  bit  of  the 

first  byte  of  the  header  or  data.  The  lowest  order  term  is  0  * 

X  **  0  for  both  cases. 

DIVIDE  the  constructed  polynomial  by  the  CRC-16  polynomial  X  **  16  + 


X  **  15  +  X  **  2  +  1  modulo  2,  obtaining  a  quotient  that  is 
discarded  and  the  16 -bit  remainder. 

TRANSMIT  the  remainder  as  the  LOCALLY_GENERATED_CRC_REMAINDER 


PROCESS  NAME:  CHECK  SELECT  BIT 

PROCESS  NUMBER:  1.2.8 

PROCESS  DESCRIPTION: 

SEPARATE  VAL ID_CRC_S OH/DLE_PACKET  into  VALID_SOH_PACRET  and  VAL ID_DLE_PACKET 
IF  VAL ID_DLE_ PACKET  select  bit  not  set  then 
Output  INVALIDJDLEJPACKET 
ELSE  output  VALID_DLE_PACKET 
Output  VALID_SOH_PACKET 

Output  VAL ID_CRC_ENQ_PACKET  as  VALID_ENQ_PACKET 


PROCESS  NAME:  DECODE  ENQ  PACKET 

PROCESS  NUMBER:  1.3.1 

PROCESS  DESCRIPTION: 

IF  TYPE  equal  00000001  then 

Output  RECEIVED_JACK_PACKET 
ELSEIF  TYPE  equal  00000010  then 
Output  RECEIVED_NAK_PACKET 
ELSEIF  TYPE  equal  OOOOOoIl  then 
Output  RECEIVED_REP_PACKET 
ELSEIF  TYPE  equal  00000110  then 
Output  RECETVED_STRT_PACKET 
ELSE  output  RECE IVED_STACK_PACKE T 
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PROCESS  NAME:  SET  NAK  TRANSMIT  FLAG 

PROCESS  NUMBER:  1.3.2 

PROCESS  DESCRIPTION:  man 

IF  Input  =  INVALID_BLKCK1,  INVALID_BLKCK2,  INVALID_BLRCK3,  or  PACKET_NON_ 

ABUT  then 

Output  a  NAR_TRAN SMIT— FLAG  and 
Output  an  INVALID_PACKETS  flag 
ELSE  Null 


PROCESS  NAME:  SET  NEGATIVE  ACKNOWLEDGE  FLAG,  RESET  TIMER 

PROCESS  NUMBER:  1.3.3 

PROCESS  DESCRIPTION:  _ __  _ .  _  ..™T 

IF  Input  =  HEAD£R_FORMAT_ERROR.  INVALID.DATA.LENGTH.INVALiD^DLE  ’ 

INVALID_STRT_PACKET,  INVALID_STACK_PACKET,  DISAGREE,  or  INVALID_PACKETS 

Output  a  SET  flag  to  SNAK_FILE  and  to  COUNT_ERRORS_PROCESS 
Reset  REPLY  TIMER 
ELSE  Null 


PROCESS  NAME:  CHECK  STRT  SELECT  BIT 

PROCESS  NUMBER:  1.3.4 

PROCESS  DESCRIPTION: 

IF  RECEIVED_STRT_PACKET  select  bit  set  then 
Output  VALID_STRT_PACKET 
ELSE  output  INVALID_STRTJPACKET 


PROCESS  NAME:  CHECK  STACK  SELECT  BIT 

PROCESS  NUMBER:  1.3.5 

PROCESS  DESCRIPTION: 

IF  RECEIVED_STACK_PACKET  select  bit  set  then 
Output  VAL ID_STACK_PACRE T 
ELSE  output  INVALID_STACK_PACKET 


PROCESS  NAME:  CHECK  NUM  FIELD  TO  R 

PROCESS  NUMBER:  1.3.6 

PROCESS  DESCRIPTION: 

IF  RECEIVED_REP_PACKET  NUM  field  value  equal  to 
Output  AGREE 
ELSE  output  DISAGREE 


the  current  R_FILE  value  then 
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PROCESS  NAME:  SET  ACKNOWLEDGE  FLAG,  RESET  TIMER 

PROCESS  NUMBER:  1.3.7 

PROCESS  DESCRIPTION: 

IF  Input  =  AGREE,  INCREMENT_R,  or  VALID_STACK_PACKET  then 
Output  a  SET  flag  to  SACKJFILE 
ELSE  Null 


PROCESS  NAME:  COUNT  ERRORS  (NAK) 

PROCESS  NUMBER:  1.3.8 

PROCESS  DESCRIPTION: 

INCREMENT  counter  on  SET  input 


IF  counter  =  49  then 
Output  TRANSIENT 


ERROR_TRRESHOLD_COU  NTER_OVERFLOW 


Reset  counter  to  0 


ELSE  Null 


PROCESS  NAME:  N=N+1 

PROCESS  NUMBER:  1.4.1 

PROCESS  DESCRIPTION: 

OUTPUT  N  =  ODD  when 

Reception  of  INITIALIZE_HNK  (N=l) 
Reception  of  VALID_STRT_PACKET  (N=ODD) 
OUTPUT  N  =  EVEN  when 

Reception  of  VALID_STRTJ?ACKET  (N=EVEN) 


PROCESS  NAME:  GENERATE  NEGATIVE  ACKNOWLEDGE  PACKET 

PROCESS  NUMBER:  1.4.2 

PROCESS  DESCRIPTION: 

IF  SNAK_JILE  set  then 

Output  NAK_PACKET  of  the  following  format:  ENQ  <  NAKTYPE  +  REASON  + 

FLAG'  +  RESP  +  FILL  +  AD  DR  + 
BLKCK3 

ELSE  Null 


PROCESS  NAME:  GENERATE  START  PACKET 

PROCESS  NUMBER:  1.4.3 

PROCESS  DESCRIPTION: 

IF  N  =  ODD  or  TIMEOUT_STRT  is  inputed  then 

Output  STRT_PACKET  of  the  following  format:  ENQ  +  STRTTYPE  +  STRTSUB  + 

FUGS  +  FILL  +  FILL  +  AD  DR  + 
BLRCR3 

ELSE  Null 
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PROCESS  NAME:  GENERATE  START  ACKNOWLEDGE  PACKET 

PROCESS  NUMBER:  1.4.4 

PROCESS  DESCRIPTION: 

IF  N  =  EVER  or  TI ME ODT_ST ACK  is  inputted  then 

Output  STACK_PACKET  of  the  following  format:  ENQ  +  STCKTYPE  +  STCKSUB  + 

FLAGS  +  FILL  +  FILL  +  AD DR  + 
BLKCK3 

Once  STACK_PACKET  is  transmitted  then 

Output  INITIALIZATION  ON  OTHERJSND  flag 

ELSE  Null 


PROCESS  NAME:  GENERATE  ACKNOWLEDGE  PACKET 

PROCESS  NUMBER:  1.4.5 

PROCESS  DESCRIPTION: 

IF  SACKJFILE  is  set  then 

Output  as  ACK_PACKET  of  the  following  format:  ENQ  +  ACKTYPE  +  ACKSUB  + 

FLAGS  +  RESP  +  FILL  + 

AD DR  +  BLKCK3 

ELSE  Null 


PROCESS  NAME:  GENERATE  REP  PACKET 

PROCESS  NUMBER:  1.4.6 

PROCESS  DESCRIPTION: 

IF  SREPJFILE  set  then 

Output  an  REP_PACKET  of  the  following  format:  ENQ  +  REPTYPE  +  REPSUB  + 

FLAGS  +  FILL  +  NUM  + 

AD DR  +  BLKCK3 

ELSE  Null 


PROCESS  NAME:  CLEAR  NEGATIVE  ACKNOWLEDGE  FLAG 

PROCESS  NUMBER:  1.4.7 

PROCESS  DESCRIPTION: 

UPON  transmission  of  a  NAK_PACKET 

Output  flag  to  clear  the  SNAK_FILE 


PROCESS  NAME:  IF  INITIALIZATION  THEN  PAD  PACKET 

PROCESS  NUMBER:  1.4.8 

PROCESS  DESCRIPTION: 

IF  Input  is  INITIALIZE_LINR  then 

Add  PAD  SEQUENCE  (11111111)  to  STRT_PACKET 
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ELSE  pass  STRT_PACKET  as  is 


PROCESS  NAME:  CLEAR  ACKNOWLEDGE  FLAG 

PROCESS  NUMBER:  1.4.9 

PROCESS  DESCRIPTION: 

UPON  transmission  of  a  ACK_PACKET 

Output  flag  to  clear  the  SNAK_FILE 


PROCESS  NAME:  CLEAR  SREP  FLAG 

PROCESS  NUMBER:  1.4.10 

PROCESS  DESCRIPTION: 

UPON  transmission  of  a  REP_PACKET 

Output  flag  to  clear  the  SREP_FILE 


PROCESS  NAME:  PROCESS  NUM  FIELD 

PROCESS  NUMBER:  1.5.1 

PROCESS  DESCRIPTION: 

SET  R  =  NUM  field  value 

Output  R  value  as  INCREMENT_R  to  FILE 
Output  VALID_SOH_PACKET 


PROCESS  NAME:  PROCESS  RESP  FIELD 

PROCESS  NUMBER:  1.5.2 

PROCESS  DESCRIPTION: 

IF  RESP  field  value  from  a  VALID_SOH_PACKET  or  RECEIVED J1CK_PACKET  or  INVALID. 
DATA_LENGTR  or  RECEIVED_NAK_PACKET  is  greater  than  A_FILE  value  then 
SET  A  =  RESP  field  value 

Output  VALID_SOH_PACKET  as  TRAN SMITTED_PRIMARY_NODE_TRAN SPORT JPACKET 
Output  a  value  to  A_FILE 

ELSE  output  VALID_SOH__PACKET  as  TRANSMITTED_PRIMARY_NODE_TRANSPORT_PACKET 


PROCESS  NAME:  GENERATE  MAINTENANCE  MODE  PACKETS 

PROCESS  NUMBER:  1.6.1 

PROCESS  DESCRIPTION: 

UPON  reception  of  a  VALID _DLE_PACKET 

Start  maintenance  operation  protocol  which  issues  MOP_PACKETS 


PROCESS  NAME:  GENERATE  MAINTENANCE  COMMAND 

PROCESS  NUMBER:  1.6,2 
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PROCESS  DESCRIPTION: 

OUTPUT  a  TRANSMITJDLE_PACKET  on  input  of  an  ENTER_MAINTENANCE_MODE_COMMAND 
with  the  following  format:  DLE  +  COUNT  +  FLAGS  +  FILL  +  FILL  +  ADDR  + 

BLKCK1  +  DATA  +  BLKCK2 


PROCESS  NAME:  ADD  4  SYNC  BYTES  TO  PACKET  IF  QSYNC 

PROCESS  NUMBER:  1.7.1 

PROCESS  DESCRIPTION: 

IF  QSYNC  set  in  last  packet  then 

Add  4  SYNC  bytes  to  the  following  packets  depending  on  which  is  the  next 
packet  to  arrive:  NAKJPACKETS,  ACK_PACKET,  REP_PACKET»  MOP_PACKET, 
TRAN  SMIT_DLE_PACKET 

Reset  QSYNC  bit  once  the  4  SYNC  bytes  have  been  added  to  the  appropriate 
packet 

Add  4  SYNC  bytes  to  the  following  packets  at  all  times:  STACK_PACKET, 
and  STRT_PACKET 
Output  ENQ/DLE_SYNC_PACKET 

ELSE  add  4  SYNC  bytes  to  the  following  packets  at  all  times:  STACKJPACKET, 
and  STRT_PACKET 
Output  ENQ/DLE_SYNC_PACKET 


PROCESS  NAME:  COUNT  DATA  FIELD  ADD  BLKCK2  AND  COUNT 

PROCESS  NUMBER:  1.7.2 

PROCESS  DESCRIPTION: 

IF  TRAN SMIT_PACKET  and  RECEIVEJPACKET  present  then 
Accept  incoming  TRANSPORT  JC0JLINKJ)AT4_PACKET 

Determine  the  number  of  bits  in  the  TRAN SPORT__TO_LINK_DATA*_PACKET 
Put  this  number  in  the  count  field  and  use  it  to 
Generate  BLKCK2 
Output  NOHEADERJ)ATA_PACKET 
ELSE  Null 


PROCESS  NAME:  ADD  REMAINING  HEADER  FIELDS 

PROCESS  NUMBER:  1.7.3 

PROCESS  DESCRIPTION: 

TO  NOHEADERJ3ATAJPACKET  add  ADDR  field,  NUM  field,  FLAGS  field,  RESP  field, 
and  SOH  field 

IF  COUNT  field  is  less  than  or  equal  to  4  SYNC  bytes  then 
Output  SHORTJDAT ACCOUNT 
ELSE  output  LONG_DATA_COUNT 


PROCESS  NAME:  SET  QSYNC  BIT 

PROCESS  NUMBER:  1.7.4 
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PROCESS  DESCRIPTION: 

IF  Input  is  PAD/ STRT JPACKET  or  STACKJPACKET  then 
Set  select  bit  and 
Output  QSYNC_ENQ/DLE_PACKET 
Output  QSYNC 

ELSEIF  Input  is  SHORT_DAT A_COU NT  then 
Set  select  bit  and 
Output  Q SYN C_DATA_PACKET 
ELSE  output  QSYNC_ENQ/DLE_PACKET 


PROCESS  NAME:  COUNT  HEADER  FIELD  AND  ADD  BLKCK1 

PROCESS  NUMBER:  1.7.5 

PROCESS  DESCRIPTION: 

TO  LONG_DATA_COUNT  and  QSYNC_DATA_PACKET  add  BLKCK1 
Output  LINK_DATA_PACKET 


PROCESS  NAME:  PIGGYBACK -ACKNOWLEDGE  RECEIVED.  SET  RESP 

PROCESS  NUMBER:  1.7.6 

PROCESS  DESCRIPTION: 

ADD  TJFILE  value  to  LINK_DATA_PACKET 
Clear  SACK_FILE 

Output  PIGGYBACK  JLINK_DATA__PACKET 


PROCESS  NAME:  CHECK  MODULO  256 

PROCESS  NUMBER:  1.7.7 

PROCESS  DESCRIPTION: 

IF  -255  <  (A  +  1  -  V)  <  1  and  HOLD_TABLE  contains  data  packet  entries  then 
Read  off  and  delete  first  data  packet  entry  from  top  of  table. 

Output  as  <256_LINK_PACKET 

ELSEIF  1  <  (A  +  1  -  V)  <  256  and  HOLD_TABLE  contains  data  packet  entries  then 
Read  off  and  delete  first  data  packet  entry  from  top  of  table 
Output  as  <256 JLINK_PACKET 

ELSEIF  -255  <  (A  +  1  -  V)  <  1  or  1  <  (A  +  1  -  V)  <  256  then 

Output  PIGGYBACKED_LINKED_J)ATA_PACKET  as  <256 JLINKJPACKET 
ELSE  output  PIGGYBACKED_LINKED_DATAJPACKET  to  bottom  of  HOLDJTABLE 


PROCESS  NAME:  INCREMENT  PACKET  COUNT 

PROCESS  NUMBER:  1.7.8 

PROCESS  DESCRIPTION: 

IF  V  <  256  then 
V  =  V  +  1 
T  =  V  +  1 
Assign  NUM  =  V 
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Output  COUNT ED_LINK_DATA_PACKET 
Update  V_FILE  and  T_FILE 
ELSE  V  =  1 
T  =  2 

Assign  NUM  =  V 

Output  COUNT ED_LINK_DATA_PACKET 
Update  V_FILE  and  T_FILE 


PROCESS  NAME;  CHECK  RETRANSMIT 

PROCESS  NUMBER;  1.7.10 

PROCESS  DESCRIPTION; 

IF  T  -  V  =  1  then 

Output  COUNT ED_LINK_DATAJPACKET  to  NOSYNC_PRIMARY_TO_SECONDARY_DATA_ 
PACKET 

ELSE  output  START  flag 


PROCESS  NAME;  ADD  4  SYNC  BYTES  TO  DATA  PACKET  IF  QSYNC  OR  INIT 

PROCESS  NUMBER:  1.7.11 

PROCESS  DESCRIPTION: 

IF  Input  is  a  QSYNC  flag  or  V_FILE  value  of  1  or  the  first  packet  of  the 
RETRANSMIT_PACKETS  then 
Add  4  SYNC  bytes  and 

Output  as  PRIMARY_TO_SECONDARY_DATA_PACKET 
ELSE  output  as  PRIMARY_TO_SECONDARY_DATAJPACKET 


PROCESS  NAME:  LOAD  AND  DELETE  MEMORY 

PROCESS  NUMBER:  1.7.12 

PROCESS  DESCRIPTION: 

IF  COUNT ED_LINK_DATA_PACKET  NM  field  value  is  greater  than  the  A_FILE  value 
then 

Load  COUNT ED_LINK_DATA_PACKET  to  MEMORY 
ELSEIF  RJFILE  value  is  same  as  a  recorded  COUNTED_LINK_DATA_PACKET  then 
Delete  all  COUNT ED_LINK_PATA_PACKETS  in  MEMORY  with  NUM  file  values 
less  than  or  equal  to  the  new  RJTLE  value 
ELSE  receive  a  START  flag  then 

Output  all  recorded  COUNT JLINK_DATA*.PACKETS  as  RETRAN SMITTED_PACKETS  , 


PROCESS  NAME:  IF  STRT,  STACK,  OR  DATAJPACKET  THEN  START  TIMER 

PROCESS  NUMBER:  1.8.1 

PROCESS  DESCRIPTION: 

IF  Input  =  QSYNC_ENQ/DLE_PACKET,  STRTJPACKET,  or  STACK_PACKET  then 
Start  TIMER 

Send  LINK_ANDJMODEM_CONTROL  =  ENABLE_LINK 
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Send  a  block  to  the  driver  through  the  use  of  the  TRAN SMIT_AJLOCK_ 
COMMAND,  it  will  be  outputted  as  PRIMARY  OUTGOING  BIT_STREAM_Tn_ 
DRIVER 

ELSEIF  Input  =  PRIMARY _TO_SECONDARY_DATA_PACKET  then 
Start  TIMER 

Send  LINK_AND_dMODEK_CONTROL  =  ENABLE  LINK 

Send  a  block  t  the  driver  through  the  use  of  the  TRANSMIT_A_BLOCK_ 
COMMAND,  it  will  be  outputted  as  PRIMARY_OUTGOING_BIT  Sl’REAMJTO 
DRIVER 

Send  PRIMARY_TO_SECONDARY_DATAwPACKET  NUM  value  to  reset  TIMER  process 
ELSEIF  Input  =  RESET_SIGNAL  then 
Reset  the  TIMER 
ELSEIF  TIMER  times  out  the 
Output  TIMEOUT 
ELSE  Input  =  STOP_LINK  then 

Send  last  PRIMARY_OUTGOING_BIT_STREAM_TO.„DRIVER  packet  with  an  ENABLE. 
LINK  then 

Send  a  DISABLE.LINK  to  the  driver 


PROCESS  NAME:  RESET  TIMER 

FLOCESS  NUMBER:  1.8.2 

PROCESS  DESCRIPTION: 

IF  Input  new  AFFILE  value  then 

Compare  with  last  recorded  NUM  value 
IF  equal  then 

Reset  TIMER 
ELSE  Null 

ELSEIF  Input  is  RECEIVED.STRT.PACKET  then 
Reset  TIMER 

ELSE  Input  is  RECEIVED_STACK_PACKET  then 
Reset  TIMER 


PROCESS  NAME:  COUNT  ERRORS  (TIME) 

PROCESS  NUMBER:  1.8.3 

PROCESS  DESCRIPTION: 

EACH  time  a  TIMEOUT  occurs  then 
Increment  COUNTER 
IF  COUNTER  =  7  then 

Output  PERSISTENT.ERROR 
Reset  COUNTER 
ELSE  Null 


IDENTIFY  TIMEOUT  PACKET 
1.8.4 


PROCESS  NAME: 
PROCESS  NUMBER: 
PROCESS  DESCRIPTION 
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IF  TIMEOUT  due  to  DATA_PACKET  then 
Output  TIMEOUT_DATA 

ELSEIF  TIMEOUT  due  to  STRT  PACKET  then 
Output  TIMEOUT_STRT 
ELSE  output  TIMEOUT.STACK 


PROCESS  NAME:  TRANSMIT  BIT  STREAMS 

PROCESS  NUMBER:  2.0 


PROCESS  DESCRIPTION: 

USE  the  PHYSICAL  LEVEL  PROTOCOL  to  transmit  the  PRIMARY  OUTGOING  BIT  STREAM^ 
TO_DRIVER  to  the  SECONDARY  NODE  and  the  SECONDARY JJUTGOING_NT_5TREAM_ 

TOJDRIVER  to  the  PRIMARY  NODE. 


PROCESS  NAME:  EXECUTE  HDLC  PROTOCOL  AT  SECONDARY  NODE 

PROCESS  NUMBER:  3.0 

PROCESS  DESCRIPTION: 

USE  the  LINK  LEVEL  PROTOCOL  to  transmit  an  error  free  SECONDARY_INCOMING_BIT_ 
STREAH_FROit_DRIVER  to  the  SECONDARY  NODE  and  to  transmit  an  error  free 
RECEIVED__SECONDARY_NODE_TRAN SPO RT_PACKE T  to  the  PRIMARY  NODE. 
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Appendix  D 


Electronic  Warfare  Network  ( EWNET)  Profile 


This  appendix  contains  a  compilation  of  the  EWNET  hardware  and 
software  design  features  using  a  format  required  for  use  by  the  Digital 
Equipment  Corporation. 
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Electronic  Warfare  Network  (EWNET)  Profile 


for 


Robins  AFB,  Georgia 


18-DEC- 81 


Revision  1 


Developed  by:  Robert  H 

Approved  by: 


.  Stokes 
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Network  Profile 


“Customer  Information” 

Robins  AFB 

c/o  Mr.  Joe  Black 

WR-A1C  /  MMRR 

Robins  Air  Force  Base,  Georgia  31098 
Customer  Network  Manager:  Mr.  Roger  Boan 
Location:  Robins  Air  Force  Base 


“Digital  Account  Management 

Account  Manager: 

Software  Specialist: 

Office: 

District  Software  Manager: 


Steven  Jones 
Jim  Bell 
AID  2 

Ed  Converse 


"Application  Information" 

The  network  will  be  used  in  an  application  doing  task-to-task 
communication,  peripheral  sharing,  and  file  transfers  as  described  in 
AFIT  Thesis  "Design  of  a  Local  Computer  Network  for  the  Robins  AFB, 
Electronic  Warfare  Division  Engineering  Branch  Laboratory"  by  Robert  H. 
Stokes,  There  exist  special  modifications  to  DECnet  in  this  application 
which  constitutes  overall  functionality  constraints  and  critical 
factors . 
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“Potential  Problem  Areas 


Does  proposed  network  cross  area,  region,  district,  or  branch 
boundaries? 

NO 

Are  any  phased  installation  /  warranty  problems  foreseen? 

NO 

Any  network-related  special  purpose  hardware  or  software  involved? 

YES 

Fiber  optic  link  and  modems  for  high  speed  and  bandwidth 


“Overall  Description"' 

Digital  Supplied  Customer  Supported 

Responsible  Product  Line:  GSG 

Other  Product  Lines:  None 

Number  of  Nodes:  14  Phase  II 

3  Phase  III 

Maximum  number  of  links  on  any  node:  7 

Operating  svstems:  VMS 

RSX-11M 
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AD-A119  253  AIR  FORCE  INST  OF  TECH  WRI6HT-PATTERS0N  AFB  OH  SCHOO— ETC  F/6  9/2 

DESIGN  OF  A  LOCAL  COMPUTER  NETWORK  FOR  THE  ROBINS  AFB  ELECTRONI— ETC (U) 
DEC  81  R  H  STOKES 

UNCLASSIFIED  AFIT/GCS/EE/81D-16  NL 


5  "•  5 


"DECnet  Functionality  to  be  used 


Present 

Future 

YES 

NO 

YES  1 

Task-to-Task 

X 

File  Transfer 

X 

File  Access 

X 

Batch  /  Command  File  Submission 

X 

Batch  /  Command  File  Execution 

Down-Line  System  Loading 

X 

X 

Down-Line  Task  Loading 

Network  Command  Terminals  (homogeneous) 

X 

X 

Network  Command  Terminals  (Hetergeneous) 
Auto-Answer  Telephone 

X 

X 

Auto-Dial  Telephone 

X 

Multidrop  DDCMP 

Routing  (Satellite) 

X 

X 

Adaptive  Routing 

X 

f 
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T.inV  Dnermt ion 

Link  Number :  1 


Node  Name:  Firat  Floor  Node 
Interface:  DMC11-AR 
DMC11-MA 

Bootstrap: 

Operating  System:  RSX-11M 
Line  Speed:  1M  Baud 


Linked  to  Node  Name:  ARC 

Interface:  DMC11-AR 
DMC11-MA 

Bootstrap: 

Operating  Syatem:  RSX-llM 


"Link  Characteriatica" 


Serial  Synchronoua  Full-Duplex  Local 

"Expected  Data  Throughput" 


Average :  1M  baud 

Peak:  1H  baud 

Size  of  Average  Data  Message:  512  Bytes 

Expected  Line  Utilization:  50Z 


"DECnet  Functionality  to  be  UBed" 


Task-to-Task 
File  Transfer 
File  Access 

Batch  /  Command  File  Submission 

Batch  /  Command  File  Execution 

Down-Line  System  Loading 

Down-Line  Task  Loading 

Network  Command  Terminals  (Homogeneous) 

Network  Command  Terminals  (Hetergeneoua) 

Auto-Answer  Telephone 

Auto-Dial  Telephone 

Multidrop  DDCMP 

Routing 

Adaptive  Routing 


Present 
YES  NO 
X 
X 
X 
X 
X 


X 

X 

X 

X 

X 

X 


Future 
YES  NO 


X 

X 

X 

X 


X 
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Link  Number:  2 


Node  Nome:  First  Floor  Node  Linked  to  Node  Neme:  F-15  TEWS 
Interface:  DMC11-AR  Interface:  DMC11-AL 

DMC11-MA  DMC11-MA 

Bootstrap:  Bootstrap: 

Operating  System:  RSX-11M  Operating  System:  VMS 

Link  Speed:  1M  baud 


**Link  Characteristics** 


Serial  Synchronous  Full-Duplex  Local 


**Expected  Data  Throughput** 


Average :  1M  baud 

Peak :  1M  baud 

Size  of  Average  Data  Message:  512  bytes 

Expected  Line  Utilization:  50Z 


"DECnet  Functionality  to  be  Used** 


Present 

Future 

YES 

NO 

YES  1 

Task-to-Task 

X 

File  Transfer 

X 

File  Access 

X 

Batch  /  Command  File  Submission 

X 

Batch  /  Command  File  Execution 

X 

Down-Line  System  Loading 

X 

Down-Line  Task  Loading 

X 

Network  Command  Terminals  (Homogeneous) 

X 

Network  Command  Terminals  (hetergeneous) 

X 

Auto-Answer  Telephone 

X 

Auto-Dial  Telephone 

X 

Multidrop  DDCMP 

X 

Routing 

X 

Adaptive  Routing 

X 

M  M  M 


Link  Number:  3 


Node  Note:  First  Floor  Node 
Interface:  DMC11-AR 
DMC11-MA 

Bootstrap: 

Operating  System:  RSX-llM 
Link  Speed:  1M  baud 


Linked  to  Node  Name:  APR-38 
Interface:  DMC11-AL 
DMC11-MA 

Bootstrap: 

Operating  System:  VMS 


“Link  Characteristics 


Serial  Synchronous  Full  Local 


"Expected  Data  Throughput** 


Average: 

Peak: 

Size  of  Average  Data  Message: 
Expected  Line  Utilization: 


1M  baud 
1M  baud 
512  bytes 
50  X 


"DECnet  Functionality  to  be  Used" 


Present 

Future 

YES 

NO 

YES 

NO 

Task-toTask 

X 

File  Transfer 

X 

File  Access 

X 

Batch  /  Command  File  Submission 

X 

Batch  /  Command  Filr-  Execution 

Down-Line  System  Loading 

X 

X 

Down-Line  Task  Loading 

Network  Command  Terminals  (Homogeneous) 

X 

X 

X 

Network  Command  Terminals  (hetergeneouB) 
Auto-Answer  Telephone 

X 

X 

X 

Auto-Dial  Telephone 

X 

X 

Multidrop  DDCMP 

Routing 

X 

X 

X 

Adaptive  Routing 

X 

X 

M  M  M 


Link  Humber:  4 


Node  Name:  First  Floor  Node 
Interface:  DMC11-AR 
DMC11-MA 

Bootstrap: 

Operating  System:  RSX-11M 
Link  Speed:  1M  baud 


Linked  to  Node  Name:  EF-111A 
Interface:  DMC11-AL 
DMC11-MA 

Bootstrap: 

Operating  System:  VMS 


"Link  Characteristics 


Serial  Synchronous  Full-Duplex  Local 


"Expected  Data  Throughput" 


Average: 

Peak: 

Size  of  Average  Data  Message: 
Expected  Line  Utilization: 


1M  baud 
1M  baud 
512  bytes 
50  X 


"DECnet  Functionality  to  be  Used" 


Present 

Future 

YES 

NO 

YES 

NO 

Task-to-Task 

X 

File  Transfer 

X 

File  Access 

X 

Batch  /  Command  File  Submission 

X 

Batch  /  Command  File  Execution 

Down-Line  System  Loading 

X 

X 

Down-Line  Task  Loading 

Network  Command  Terminals  (Homogeneous) 

X 

X 

X 

Network  Command  Terminals  (Hetergeneous) 
Auto-Answer  Telephone 

X 

X 

X 

Auto-Dial  Telephone 

X 

X 

Multidrop  DDCMP 

X 

X 

Routing 

Adaptive  Routing 

X 

X 

X 
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*  N  X 


link  Number :  5 


Node  Neme:  Second  Floor  Node 
Interface!  DMC11-AR 
DMC11-MA 

Bootstrap: 

Operating  System:  RSX-11M 
Link  Speed:  1M  baud 


Linked  to  Node  Name:  ALQ-131 
Interface:  DHC11-AL 
DMC11-MA 

Bootstrap: 

Operating  System:  VMS 


**Link  Characteristics** 


Serial  Synchronous  Full-Duplex  Local 


"Expected  Data  Throughput** 


Average :  1M  baud 

Peak:  1M  baud 

Size  of  Average  Data  Message:  512  bytes 

Expected  Line  Utilization:  50  Z 


"DEC net  Functionality  to  be  Used** 


Present 

Future 

YES 

NO 

YES 

NO 

Task-to-l’ask 

X 

File  Transfer 

X 

File  Access 

X 

Batch  /  Command  File  Submission 

X 

Batch  /  Command  File  Execution 

Down-Line  System  Loading 

X 

X 

Down-Line  Task  Loading 

Network  Command  Terminals  (Homogeneous) 

X 

X 

X 

Network  Cosimand  Terminals  (Hetergeneous) 
Auto-Answer  Telephone 

X 

X 

X 

Auto-Dial  Telephone 

X 

X 

Multidrop  DDCMP 

X 

X 

Booting 

Adaptive  Routing 

X 

X 

X 

M  K  X 


Link  Number:  6 


Node  Name:  Second  Floor  Node 
Interface:  DMC11-AR 
DMC11-MA 

Bootstrap: 

Operating  System:  RSX-11M 
Link  Speed:  1M  baud 


Linked  to  Node  Name:  ALQ-155 
Interface:  DMCU-AL 
DMC11-MA 

Bootstrap: 

Operating  System:  VMS 


“Link  Characteristics** 


Serial  Synchronous  Full-Duplex  Local 


“Expected  Bata  Throughput** 


Average :  1M  baud 

Peak :  1M  baud 

Size  of  Average  Data  Message:  512  bytes 

Expected  Line  Utilization:  50  X 


"DECnet  Functionality  to  be  Used** 


Present 

Future 

YES 

NO 

YES 

NO 

Task-to-Task 

X 

File  Transfer 

X 

File  Access 

X 

Batch  /  Command  File  Submission 

X 

Batch  /  Command  File  Execution 

Down-Line  System  Loading 

X 

X 

Down-Line  Task  Loading 

Network  Command  Terminals  (Homogeneous) 

X 

X 

X 

Network  Command  Terminals  (Hetergeneous) 
Auto-Answer  Telephone 

X 

X 

X 

Auto-Dial  Telephone 

X 

X 

Multidrop  DDCMP 

X 

X 

Routing 

Adaptive  Routing 

X 

X 

X 
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link  Description 

v 

4>  Link  Number  7 


Node  Name:  Second  Floor  Node 
Interface:  DMCU-AR 
DMC11-MA 

Bootstrap: 

Operating  System:  RSX-11M 


Linked  to  Node  Name:  ALQ-119 
Interface:  DMC11-AL 
DMC11-MA 

Bootstrap: 

Operating  System:  VMS 


**Link  Characteristics*' 


Serial  Synchronous  Full-Duplex  Local 


“Expected  Data  Throughput** 


Average : 

Peak: 

Size  of  Average  Data  Message: 
Expected  Line  Utilization: 


1M  baud 
1M  baud 
51 2  bytes 
50  Z 


“DECnet  Functionality  to  be  Used** 


Present 

Future 

YES 

NO 

YES 

NO 

Task-to-Task 

X 

File  Transfer 

X 

File  Access 

X 

Batch  /  Command  File  Submission 

X 

Batch  /  Command  File  Execution 

X 

Dovn-Line  System  Loading 

X 

Down-Line  Task  Loading 

X 

Network  Command  Terminals  (Homogeneous) 

X 

X 

Network  Command  Terminals  (Hetergeneous) 

X 

Auto-Answer  Telephone 

X 

X 

Auto-Dial  Telephone 

X 

X 

Multidrop  DDCMP 

X 

X 

Routing 

X 

Adaptive  Routing 

X 

X 

r 
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Link  Number:  8 


Node  Name:  Second  Floor  Node 
Interface:  DMC11-AR 
DMC11-MA 

Bootstrap: 

Operating  System:  RSX-11M 
Link  Speed:  1M  baud 


Linked  to  Node  Name:  ALR-69 

Interface:  DMC11-AL 
DMC11-MA 

Bootstrap: 

Operating  System:  VMS 


“Link  Characteristics" 


Serial  Synchronous  Full-Duplex  Local 


“Expected  Data  Throughput 


Average : 

Peak: 

Size  of  Average  Data  Message: 
Expected  Line  Utilization: 


1M  baud 
1M  baud 
512  bytes 
50  Z 


“DECnet  Functionality  to  be  Used" 


Present 

Future 

YES 

NO 

YES  ] 

Task-to-Task 

X 

File  Transfer 

X 

File  Access 

X 

Batch  /  Command  File  Submission 

X 

Batch  /  Command  File  Execution 

Down-Line  System  Loading 

X 

X 

Down-Line  Task  Loading 

Network  Command  Terminals  (Homogeneous) 

X 

X 

Network  Command  Terminals  (Hetergeneous) 
Auto-Answer  Telephone 

X 

X 

Auto-Dial  Telephone 

X 

Multidrop  DDCMP 

Routing 

X 

X 

Adaptive  Routing 


X 


X 


Link  Number:  9 


Node  Name:  Second  Floor  Node  Linked  to  Node  Name:  EWOLS  /  ECSAS 
Interface:  DMC11-AR  Interface:  DMC11-AL 

DMC11-MA  DMC11-MA 

Bootstrap:  Bootstrap: 

Operating  System:  RSX-11M  Operating  System:  VMS 

Link  Speed:  1M  baud 


“Link  Characteristics** 


Serial  Synchronous  Full-Duplex  Local 


**Expected  Data  Throughput 


Average : 

Peak: 

Size  of  Average  Data  Message: 
Expected  Line  Utilization: 


1M  baud 
1M  baud 
512  bytes 
50  Z 


“DECnet  Functionality  to  be  Used** 


Task-to-Task 
File  Transfer 
File  Access 

Batch  /  Command  File  Submission 

Batch  /  Command  File  Execution 

Down-Line  System  Loading 

Down-Line  Task  Loading 

Network  Command  Terminals  (Homogeneous) 

Network  Command  Terminals  (Hetergeneous) 

Auto-Answer  Telephone 

Auto-Dial  Telephone 

Multidrop  DDCMP 

Routing 

Adaptive  Routing 


Present 
YES  NO 
X 
X 
X 
X 
X 


X 

X 

X 

X 

X 

X 


Future 
YES  NO 


X 

X 

X 


X 


X 


X  X  X 


Link  Number:  10 


Node  Name:  Third  Floor  Node  Linked  to  Node  Name:  B-52 
Interface:  DMC11-AR  Interface:  DMC11-AR 

DMC11-MA  DMC11-MA. 

Bootstrap:  Bootstrap: 

Operating  System:  RSX-11M  Operating  System:  RSX-11M 

Link  Speed:  1M  baud 


"Link  Characteristics" 


Serial  Synchronous  Full-Duplex  Local 

"Expected  Data  Throughput 


Average: 

Peak: 

Size  of  Average  Data  Message: 
Expected  Line  Utilization: 


1M  baud 
1M  baud 
512  bytes 
50  1 


"DECnet  Functionality  to  be  Used" 


Task-to-Task 
File  Transfer 
File  Access 

Batch  /  Command  File  Submission 

Batch  /  Command  File  Execution 

Down-Line  System  Loading 

Down-Line  Task  Loading 

Network  Command  Terminals  (Homogeneous) 

Network  Command  Terminals  (Hetergeneous) 

Auto-Answer  Telephone 

Auto  Dial  Telephone 

Multidrop  DDCMP 

Routing 

Adaptive  Routing 


Present 
YES  NO 
X 
X 
X 
X 
X 


X 

X 

X 

X 

X 

X 


Future 
YES  NO 


X 

X 

X 

X 


X 
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XXX 


Link  Number:  11 


Node  Name:  Third  Floor  Node 
Interface:  DMC11-AR 
DMC11-MA 

Bootstrap: 

Operating  System:  RSX-11M 
Link  Speed:  1M  baud 


Linked  to  Node  Name:  ALR-62 

Interface:  DMC11-AL 
DMC11-MA 

Bootstrap: 

Operating  System:  VMS 


"Link  Characteristics 


Serial  Synchronous  Full-Duplex  Local 


“Expected  Data  Throughput" 


Average: 

Peak: 

Size  of  Average  Data  Message: 
Expected  Line  Utilization: 


1M  baud 
1M  baud 
512  bytes 
50  1 


"DECnet  Functionality  to  be  Used” 


Present 

Future 

YES 

NO 

YES 

NO 

Task-to-Task 

X 

File  Transfer 

X 

File  Access 

X 

Batch  /  Command  File  Submission 

X 

Batch  /  Command  File  Execution 

Down-Line  System  Loading 

X 

X 

Down-Line  Task  Loading 

Network  Command  Terminals  (Homogeneous) 

X 

X 

X 

Network  Command  Terminals  (Hetergeneous) 
Auto-Answer  Telephone 

X 

X 

X 

Auto-Dial  Telephone 

X 

X 

Multidrop  DDCMP 

Routing 

X 

X 

X 

Adaptive  Routing 

X 

X 
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X  X  X 


Link  Number:  12 


Node  Name:  Third  Floor  Node 
Interface:  DMC11-AR 
DMC11-MA 

Bootstrap: 

Operating  System:  RSX-11M 
Link  Speed:  1M  baud 


Linked  to  Node  Name:  ALR-62 

Interface:  DMC11-AL 
DMC11-MA 

Bootstrap: 

Operating  System:  VMS 


"Link  Characteristics" 


Serial  Synchronous  Full-Duplex  Local 


"Expected  Data  Throughput" 


Average : 

Peak: 

Size  of  Average  Data  Message: 
Expected  Line  Utilization: 


1M  baud 
1M  baud 
512  bytes 
50  Z 


"DECnet  Functionality  to  be  Used" 


Ta8k-to-Task 
File  Transfer 
File  Access 

Batch  /  Command  File  Submission 

Batch  /  Command  File  Execution 

Dovn-Line  System  Loading 

Down-Line  Task  Loading 

Network  Command  Terminals  (Homogeneous) 

Network  Command  Terminals  (Hetergeneous) 

Auto-Answer  Telephone 

Auto-Dial  Telephone 

Multidrop  DDCMF 

Routing 

Adaptive  Routing 


Present 
YES  NO 
X 
X 
X 
X 
X 


X 

X 

X 

X 

X 

X 


Future 
YES  NO 


X 

X 

X 

X 


X 
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Link  Number:  13 


Node  Name:  Third  Floor  Node  Linked  to  Node  Name:  FLTS 
Interface:  DMC11-AR  Interface:  DMC11-AR 

DMC11-MA  DMC11-MA 

Bootstrap:  Bootstrap: 

Operating  System:  RSX-11M  Operating  System:  RSX-11M 

Link  Speed:  1M  baud 


"Link  Characteristics" 


Serial  Synchronous  Full-Duplex  Local 


"Expected  Data  Throughput" 


Average : 

Peak: 

Size  of  Average  Data  Message: 
Expected  Line  Utilization: 


1M  baud 
1M  baud 
512  bytes 
50  1 


"DECnet  Functionality  to  be  Used" 


Present 

Future 

YES 

NO 

YES 

NO 

Task-to-Task 

X 

File  Transfer 

X 

File  Access 

X 

Batch  /  Command  File  Submission 

X 

Batch  /  Command  File  Execution 

Down-Line  System  Loading 

X 

X 

Down-Line  Task  Loading 

Network  Command  Terminals  (Homogeneous) 

X 

X 

X 

Network  Command  Terminals  (Hetergeneous) 
Auto-Answer  Telephone 

X 

er 

X 

Auto-Dial  Telephone 

X 

X 

Multidrop  DDCMP 

Routing 

X 

X 

X 

Adaptive  Routing 

X 

X 

I 


I  \ 

I 


Link  Description 

Link  Number:  14 


Node  Name:  Third  Floor  Node  Linked  to  Node  Name:  ALQ-125 
Interface:  DMC11-AR  Interface:  DMC11-AR 

DMC11-MA  DMC11-MA 

Bootstrap:  Bootstrap: 

Operating  System:  RSX-11M  Operating  System:  RSX-11M 

Link  Speed:  1M  baud 


**Link  Characteristics** 


Serial  Synchronous  Full-Duplex  Local 


“Expected  Data  Throughput 


Average : 

Peak: 

Size  of  Average  Data  Message: 
Expected  Line  Utilization: 


1M  baud 
1M  baud 
512  bytes 
50  X 


"DECnet  Functionality  to  be  Used** 


Present 

Future 

YES 

NO 

YES 

NO 

Task-to-Task 

X 

File  Transfer 

X 

File  Access 

X 

Batch  /  Command  File  Submission 

X 

Batch  /  Command  File  Execution 

X 

Down-Line  System  Loading 

X 

Down-Line  Task  Loading 

X 

Network  Command  Terminals  (Homogeneous) 

X 

X 

Network  Command  Terminals  (Hetergeneous) 

X 

Auto-Answer  Telephone 

X 

X 

Auto-Dial  Telephone 

X 

X 

Multidrop  DDCMP 

X 

X 

Routing 

X 

Adaptive  Routing 

X 

X 

( 


ti 


387 


x  x  x 


Link  Number:  15 


Node  Name:  Third  Floor  Node  Linked  to  Node  Name:  Second  Floor  Node 
Interface:  DMC11-AR  Interface:  DMC11-AR 

DMCU-MA  DMC11-MA 

Bootstrap:  Bootstrap: 

Operating  System:  RSX-11M  Operating  System:  RSX-11M 

Link  Speed:  1M  baud 


“Link  Characteristics’* 


Serial  Synchronous  Full-Duplex  Local 


“Expected  Data  Throughput” 


Average: 

Peak: 

Size  of  Average  Data  Message: 
Expected  Line  Utilization: 


1M  baud 
1M  baud 
512  bytes 
100  Z 


“DECnet  Functionality  to  be  Used” 


Present 

Future 

YES 

NO 

YES  1 

Task-to-Task 

X 

File  Transfer 

X 

File  Access 

X 

Batch  /  Command  File  Submission 

X 

Batch  /  Command  File  Execution 

Down-Line  System  Loading 

X 

X 

Down-Line  Task  Loading 

Network  Command  Terminals  (Homogeneous) 

X 

X 

Network  Command  Terminals  (Hetergeneous) 
Auto-Answer  Telephone 

X 

X 

Auto_pial  Telephone 

X 

Multidrop  DDCMP 

Routing 

Adaptive  Routing 

X 

X 

X 
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Link  Number:  16 


Node  Name:  Second  Floor  Node 
Interface:  DMC11-AR 
DMC11-MA 

Bootstrap: 

Operating  System:  RSX-11M 
Link  Speed:  1H  baud 


Linked  to  Node  Name:  First  Floor  Node 
Interface:  DMCU-AR 
DMC11-MA 

Bootstrap: 

Operating  System:  RSX-11M 


"Link  Characteristics* 


Serial  Synchronous  Full-Duplex  Local 


"Expected  Data  Throughput* 


Average : 

Peak: 

Size  of  Average  Data  Message: 
Expected  Line  Utilization: 


1M  baud 
1M  baud 
512  bytes 
100  Z 


"DECnet  Functionality  to  be  Used* 


Task-to-Task 
File  Transfer 
File  Access 

Batch  /  Command  File  Submission 

Batch  /  Command  File  Execution 

Down-Line  System  Loading 

DovnJLine  Task  Loading 

Network  Command  Terminals  (Homogeneous) 

Network  Command  Terminals  (Hetergeneous) 

Auto-Answer  Telephone 

Auto-Dial  Telephone 

Multidrop  DDCMP 

Routing 

Adaptive  Routing 


Present 
YES  NO 
X 
X 
X 
X 
X 


Future 
YES  NO 
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Link  Number:  17 


Node  Name:  First  Floor  Node  Linked  to  Node  Name:  Third  Floor  Node 
Interface:  DMC11-AR  Interface:  DMC11-AR 

DMC11-MA  DMC11-MA 

Bootstrap:  Bootstrap: 

Operating  System:  RSX-11M  Operating  System:  RSX-11M 

Link  Speed:  1M  baud 


"Link  Characteristics** 


Serial  Synchronous  Full-Duplex  Local 


**Expected  Data  Throughput** 


Average : 

Peak: 

Size  of  Average  Data  Message: 
Expected  Line  Utilization: 


1M  baud 
1M  baud 
512  bytes 
100  Z 


"DECnet  Functionality  to  be  Used** 


Task-to-Task 
File  Transfer 
File  Access 

Batch  /  Command  File  Submission 

Batch  /  Command  File  Execution 

Dovn-Line  System  Loading 

Dovn-Line  Task  Loading 

Network  Command  Terminals  (Homogeneous) 

Network  Command  Terminals  (Hetergeneous) 

Auto-Answer  Telephone 

Auto-Dial  Telephone 

Multidrop  DDCMP 

Routing 

Adaptive  Routing 


Present 
YES  NO 
X 
X 
X 
X 
X 


X 

X 

X 

X 


Future 
YES  NO 


X 

X 

X 


X 


X 


K  «  K 


Host  Number:  1 


Host  Name:  ARC 
Location:  Robins  AFB 
Expected  Date  On-Line:  1983 


Operating  System:  RSX-11M 

Languages  Supported:  Fortran  and  Pascal 

Other  Layered  S/W  Products: 

A/D  Scanning? 

D/A  Conversion? 

Graphics? 

27 80 ,37 80 .HASP , 3 27 1 , SNA? 

Other  Interrupt  Intensive  S/W? 


DECnet  Version:  3.0 


NO 

NO 

NO 

NO 

NO 


CPU:  PDP-11/34 


Terminals:  Number  Type 

3  VT-100 

Other  Peripherals: 

Number  Type 

1  DR-11 

1  LA-120 

1  TJE-16 

1  RJM-02 

1  LP-11 


Main  Memory:  1024  K  bytes  MOS 

Speeds 
9600  baud 


Total  Number  of  Links?  1 


Total  Throughput:  (Bits/Second) 

IN  OUT 

Average:  125  R  125  K 

Peak:  125  K  125  K 


Expected  CPU  Utilization  by  DECnet:  50  Z 


"Host  Application" 

This  host  will  use  DECnet  for  all  uses  listed  as  applicable  under 
Link  Description  1. 


Host  Name:  F-15  TEWS 
Location:  Robins  AFB 
Expected  Date  On-Line:  Jan  1982 

Operating  System:  VMS 

Languages  Supported:  Fortran  and  Pascal 
Otber  Layered  S/W  Products: 

A/D  Scanning? 

D/A  Conversion? 

Graphics? 

27  80 ,37  80 .HASP ,3  27 1 , SNA? 
Other  Interrupt  Intensive 

CP0:  VAX-11/780 

Terminals:  Number  Type 

8  VT-100 

1  VT-125 


Host  Number:  2 


DECnet  Version:  1.3 


YES 

YES 

YES 

NO 

S/W?  YES 

Main  Memory:  1024  K  bytes  MOS 

Speeds 
9600  baud 
9600  baud 


Other  Peripherals: 


Number 

Type 

1 

DR- 11 

1 

LP-11 

1 

TEE- 16 

2 

REM-03 

1 

LA- 120 

Total  Number  of  Links:  1 

Total  Throughput:  (Bits/Second) 

IN 

OUT 

Average : 

125  K 

125  K 

Peak: 

125  K 

125  K 

Expected  CPD  Utilization  by  DECnet?  50  X 


"Host  Application" 

This  host  will  use  DECnet  for  all  uses  listed  as  applicable  under 
Link  Description  2. 
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Boat  Description 


Host  Name:  APR-38  Host  Number:  3 

Location:  Robins  APB 

Expected  Date  On-Line:  Sept  1982 


Operating  System:  VMS 

Languages  Supported:  Fortran  and  Pascal 

Other  Layered  S/W  Products: 

A/D  Scanning? 

D/A  Conversion? 

Graphics? 

27  80 .37  80 .HASP .3  27 1 , SNA? 

Other  Interrupt  Intensive  S/W? 


DECnet  Version:  1.3 


YES 

YES 

YES 

NO 

NO 


CPO:  VAX-11/780 


Terminals:  Number  Type 

8  VT-100 

1  VT-125 

Other  Peripherals: 

Number  Type 

1  DR-11 

1  LP-11 

1  TEE- 16 

2  REM-03 

1  LA-120 


Total  Number  of  Linkr?  1 
Total  Throughput:  (Bits/Second) 

IN 

Average:  125  K 

Peak:  125  K 


Main  Memory:  1024  K  bytes  MOS 

Speeds 
9600  baud 
9600  baud 


OUT 
125  K 
125  K 


Expected  CPU  Utilization  by  DECnet?  50  Z 


"Host  Application** 

This  host  will  use  DECnet  for  all  uses  listed  as  applicable  under 
Link  Description  3. 
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Host  Name:  EF-1UA 

Location:  Robins  AFB 

Expected  Date  On-Line:  Dec  1982 


Host  Number:  4 


Operating  System:  VMS 

DECnet  Version:  1.3 

Languages  Supported:  Fortran 

and  Pascal 

Other  Layered  S/W  Products: 

A/D  Scanning? 

YES 

D/A  Conversion? 

YES 

Graphics? 

YES 

27 80 ,37 80 .HASP, 

3271. SNA? 

NO 

Other  Interrupt 

Intensive 

S/W?  YES 

CPU:  VAX-11/780 

Main  Memory:  1024  X  bytes  MOS 

Terminals:  Number 

Type 

Speeds 

4 

VT-100 

9600  baud 

1 

VT-125 

9600  baud 

Other  Peripherals: 

Number 

Type 

1 

DR- 11 

1 

LP-11 

2 

TEE-16 

2 

REM-03 

1 

LA- 120 

Total  Number  of  Links:  1 

Total  Throughput:  (Bits/Seconds) 

IN 

OUT 

Average : 

125  K 

125  X 

Peak: 

125  K 

125  X 

Expected  CPU  Utilization  by  DECnet:  50  Z 


"Host  Application** 

This  host  will  use  DECnet  for  all  uses  listed  as  applicable  under 
Link  Description  4. 


i 
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Host  Name:  ALQ-13 1 

Location:  Robins  AFB 

Expected  Date  On-Line:  15-Jun-81 


Host  Number:  5 


Operating  System:  VMS 


DECnet  Version:  1.3 


Languages  Supported:  Fortran  and  Pascal 
Other  Layered  S/W  Products: 


A/D  Scanning? 

NO 

D/A  Conversion? 

NO 

Graphics? 

NO 

27 80 ,37 80 .HASP, 

3 271, SNA? 

NO 

Other  Interrupt 

Intensive 

S/W?  NO 

CPU:  VAX-11/780 

Main  Memory: 

Terminals:  Number 

Type 

Speeds 

8 

VT-100 

9600  baud 

Other  Peripherals: 

Number 

Type 

1 

DR- 11 

1 

LP-11 

1 

TEE-16 

1 

REM-03 

1 

LA- 120 

Total  Number  of  Links:  1 

Total  Throughput:  (Bits /Second) 

IN 

OUT 

Average: 

125  K 

125  K 

Peak: 

125  K 

125  K 

1024  K  bytes  MOS 


Expected  CPU  Utilization  by  DECnet:  50  Z 


“Host  Application” 

Ibis  host  will  use  DECnet  for  all  uses  listed  as  applicable  under 
Link  Description  5. 
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Host  Description 

Host  Name:  ALQ-155  Host  Number:  6 

Location:  Robins  AFB 

Expected  Date  On-Line:  lS-Jun-81 


Operating  System:  VMS 

Languages  Supported:  Fortran  and  Pascal 

Other  Layered  S/W  Products: 

A/D  Scanning? 

D/A  Conversion? 

Graphics 

27 80 ,3780 .HASP, 3271. SNA? 
Other  Interrupt  Intensive 

CPU:  VAX-11/780 


Terminals:  Number  Type 

6  VT-100 

Other  Peripherals: 

Number  Type 

1  DR- II 

1  LP-11 

1  TEE- 16 

1  REM-03 

1  LA-120 


Total  Humber  of  Links?  1 
Total  Throughput:  (Bits/Second) 

IN 

Average:  125  K 

Peak:  125  R 


DECnet  Version:  1.3 


NO 

NO 

NO 

NO 

S/W?  NO 

Main  Memory:  1024  K  bytes  MOS 

Speeds 
9600  baud 


ODT 
125  K 
125  K 


Expected  CPU  Utilization  by  DECnet:  50  Z 


’’Host  Application’’ 

This  host  vill  use  DECnet  for  all  uses  listed  as  applicable  under 
Link  Description  6. 


j 
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Host  Name:  ALQ-119 
Location:  Robins  AFB 
Expected  Date  On-Line:  1983 


Host  Number:  7 


Operating  System:  VMS  DECnet  Version:  1.3 

Languages  Supported:  Fortran  and  Pascal 

Other  Layered  S/W  Products: 

A/D  Scanning?  NO 

D/A  Conversion?  NO 

Graphics?  NO 

27 80 ,37 80 .HASP . 3271, SNA?  NO 

Other  Interrupt  Intensive  S/W?  NO 

CPU:  VAX-11/780  Main  Memory:  1024  K  bytes  MOS 

Terminals:  Number  Type  Speeds 

4  VT-100  9600  baud 

Other  Peripherals: 

Number 
1 
1 
1 
1 
1 

Total  Number  of  Links:  1 

Total  Throughput:  (Bits/Second) 

IN  OUT 

Average:  125  K  125  K 

Peak:  125  X  125  K 

Expected  CPU  Utilization  by  DECnet:  50  Z 


"Host  Application" 

This  host  will  use  DECnet  for  all  uses  listed  as  applicable  under 
Link  Description  7. 


Type 
DR-U 
LP-11 
TEE- 16 
REM-03 
LA- 120 
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Host  Name:  ALR-69 

Location:  Robins  AFB 

Expected  Date  On-Line:  Jan  1982 


Host  Number:  8 


Operating  System:  VMS  DECnet  Version:  1„3 

Languages  Supported:  Fortran  and  Pascal 

Other  Layered  S/W  Products: 

A/D  Scanning?  NO 

D/A  Conversion?  NO 

Graphics?  NO 

27 80 ,37 80 .HASP, 3 27 l, SNA?  NO 

Other  Interrupt  Intensive  S/W?  NO 

CPU:  VAX- 11/ 7 80  Main  Memory:  1024  R  bytes  MOS 

Terminals:  Number  Type  Speeds 

4  VT-100  9600  baud 

Other  Peripherals: 

Number 
1 
1 
1 
1 
2 

Total  Number  of  Links:  1 

Total  Throughput:  (Bits/Second) 

IN  OUT 

Average:  125  K  125  K 

Peak:  125  K  125  K 

Expected  CPU  Utilization  by  DECnet:  50  Z 


"Host  Application" 

This  host  will  use  DECnet  for  all  uses  listed  as  applicable  under 
Link  Description  8. 


Type 
DR- 11 
LA- 120 
LP-11 
TEE-16 
REM-03 
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Host  Name:  EWOLS/ECSAS  Host  Number:  9 

Location:  Robins  AFB 

Expected  Date  On-Line:  15-Jun-81 

Operating  System:  VMS  DECnet  Version:  1.3 

Languages  Supported:  Fortran  and  Pascal 

Other  Layered  S/W  Products: 

A/D  Scanning?  NO 

D/A  Conversion?  NO 

Graphics?  NO 

27 80 ,3780, HASP. 3271, SNA?  NO 

Other  Interrupt  Intensive  S/W?  NO 

CPU:  VAX-11/780  Main  Memory:  1024  K  bytes  MOS 

Terminals:  Number  Type  Speeds 

22  VT-100  9600  baud 

Other  Peripherals: 

Number 
1 
6 
1 
2 
1 

Total  Number  of  Links:  1 

Total  Throughput:  (Bits/Second) 

IN  OUT 

Average:  125  K  125  K 

Peak:  125  K  125  K 

Expected  CPU  Utilization  by  DECnet:  50  % 


"Host  Application" 

This  Host  will  use  DECnet  for  all  uses  listed  as  applicable  under 
Link  Description  9. 


Type 
LP-11 
DR- 11 
TEE-16 
REM-03 
LA- 120 


Host  Name:  B-52 
Location:  Robins  AFB 
Expected  Date  On-Line:  1963 


Host  Number:  10 


Operating  System:  RSX-11M 

Languages  Supported:  Fortran  and  Pascal 

Other  Layered  S/W  Products: 

A/D  Scanning? 

D/A  Conversion? 

Graphics? 

27 80 .37 80 .HASP , 3 27 1 .SNA? 

Other  Interrupt  Intensive  S/W? 


DECnet  Version:  3.0 


NO 

NO 

NO 

NO 

NO 


CPU:  PDP-11/34 


Terminals:  Number  Type 

2  VT-100 

Other  Peripherals: 

Number  Type 

1  DR-11 

1  LP-11 

1  TJE-16 

1  RJM-02 

1  LA-120 


Total  Number  of  Links:  1 


Main  Memory:  1024  R  bytes  MOS 

Speeds 
9600  baud 


Total  Throughput:  (Bits/Second) 

IN  ODT 

Average:  125  K  125  K 

Peak:  125  K  125  K 

Expected  CPU  Utilization  by  DECnet:  50  Z 


“Host  Application" 

This  host  will  use  DECnet  for  all  uses  listed  as  applicable  under 
Link  Description  10. 


400 


Halt  Description 


Host  Name:  ALR-62  Host  Number:  11 

Location:  Robins  AFB 
Expected  Date  On-Line:  Dec  1981 

Operating  System:  VMS 
Languages  Supported:  Fortran  and  Pascal 
Other  Layered  S/U  Products: 

A/D  Scanning? 

D/A  Conversion? 

Graphics? 

27  80 ,37  80  .HASP  ,3  27 1 , SNA? 

Other  Interrupt  Intensive  S/W? 

CPU:  VAX-11/780  Main  Memory:  1024  R  bytes  MOS 


Terminals:  Number 

Type 

Speeds 

6 

VT-100 

9600  baud 

Other  Peripherals: 

Number 

Type 

1 

DR- 11 

1 

LP-11 

1 

TEE- 16 

1 

REM-03 

1 

LA- 120 

Total  Number  of  Links:  1 

Total  Throughput:  (Bits/Second) 

IN 

OUT 

Average : 

125  K 

125  X 

Peak: 

125  K 

125  R 

Expected  CPU  Utilization  by  DECnet:  50  Z 


DECnet  Version:  1.3 


NO 

NO 

NO 

NO 

NO 


“Host  Application** 

This  host  will  use  DECnet  for  all  uses  listed  as  applicable  under 
Link  Description  11. 


i 
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Host  Name:  ALR-46 

Location:  Robins  AFB 

Expected  Date  On-Line:  Feb  1982 


Host  Number:  12 


Operating  System:  VMS 

DECnet  Version 

Languages  Supported:  Fortran 

and  Pascal 

Other  Layered  S/tf  Products: 

A/D  Scanning? 

NO 

D/A  Conversion? 

NO 

Graphics? 

YES 

27 80 .37 80 .HASP, 

3271. SNA? 

NO 

Other  Interrupt 

Intensive 

S/W?  NO 

Terminals:  Number 

Type 

Speeds 

6 

VT-100 

9600  baud 

2 

VT-125 

9600  baud 

1 

TER -40 27 

9600  baud 

Other  Peripherals: 

Number 

Type 

1 

DR- 11 

1 

LP-U 

1 

TEE- 16 

2 

REM-03 

1 

LA- 120 

Total  Number  of  Links:  1 

Total  Throughput:  (Bits/Second) 

IN 

OUT 

Average : 

125  K 

125  K 

Peak: 

125  K 

125  K 

Expected  CPU  Utilization  by  DECnet:  50  2 


"Host  Application** 

This  host  will  use  DECnet  for  all  uses  listed  as  applicable  under 
Link  Description  12. 
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Host  Name:  FITS 

Location:  Robins  AFB 

Expected  Date  On-Line:  Sept  1982 


Host  Number:  13 


Operating  System:  RSX-11M 

Languages  Supported:  Fortran  and  Pascal 

Other  Layered  S/W  Products: 

A/D  Scanning? 

D/A  Conversion? 

Graphics? 

27  80 ,37  80 .HASP ,3  27 1 , SNA? 

Other  Interrupt  Intensive 

CPU:  PDP-11/34 

Terminals:  Number  Type 

4  VT-100 

Other  Peripherals: 

Number 
1 
1 
1 
1 
1 

Total  Number  of  Links:  1 

Total  Throughput:  (Bits/Second) 

IN 

Average:  125  K 

Peak:  125  K 


DECnet  Version:  3.0 


NO 

NO 

NO 

NO 

S/W?  NO 

Main  Memory:  1024  K  bytes  MOS 

Speeds 
9600  baud 


OUT 
125  K 
125  K 


Type 
DR- 11 
LA- 120 
TJE-16 
RJM-02 
LP-11 


Expected  CPU  Utilization  by  DECnet:  50  Z 


"Host  Application" 

This  host  will  use  DECnet  for  all  uses  listed  as  applicable  under 
Link  Description  13. 
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Host  Name:  ALQ-125 

Location:  Robins  AFB 

Expected  Date  On-Line:  Nov  1981 


Host  Number:  14 


Operating  System:  RSX-11M 

DECnet  Vers; 

Languages  Supported:  Fortran 

and  Pascal 

Other  Layered  S/W  Products: 

A/D  Scanning? 

NO 

D/A  Conversion? 

NO 

Graphics? 

NO 

27 80 ,37 80 .HASP. 

3  271. SNA? 

NO 

Other  Interrupt 

Intensive 

S/W?  NO 

CPU:  PDP-11/34 

Main  Memory 

Terminals:  Number 

Type 

Speeds 

4 

VT-100 

9600  baud 

Other  Peripherals: 

Number 

Type 

1 

DR- 11 

1 

LA-120 

1 

TJE-16 

1 

RJM-02 

1 

LP-11 

Total  Number  of  Links:  1 

Total  Throughput:  (Bits/Second) 

IN 

OUT 

Average : 

125  K 

125  X 

Peak: 

125  X 

125  K 

Expected  CPU  Utilization  by  DECnet:  50  Z 

"Host  Application** 

This  host  vill  use  DECnet  for  all  uses  listed  as  applicable  under 
Link  Description  14. 


Nod*  Description 


Node  Name:  First  Floor  Node  Node  Number:  1 

Location:  Robins  AFB 
Expected  Date  On-Line:  1983 


Operating  System:  RSX-11M 

Languages  Supported:  Fortran  and  Pascal 

Other  Layered  S/N  Products: 

A/D  Scanning? 

D/A  Conversion? 

Graphics 

27 80 .37 80 .HASP , 3 27 1 , SNA? 

Other  Interrupt  Intensive  S/W? 


DECnet  Version:  3.0 


NO 

NO 

NO 

NO 

NO 


CPU:  PDP-11/70 


Terminals:  Number  Type 

2  VT-100 

Other  Peripherals: 

Number  Type 

1  DR-U 

1  LA-120 

1  LP-11 

3  RWM-02 


Total  Number  of  Links:  3 
Total  Throughput:  (Bits/Second) 

IN 

Average:  125  K 

Peak:  125  K 


Main  Memory:  2048  K  bytes  MOS 

Speeds 
9600  baud 


OUT 
125  K 
125  K 


Expected  CPU  Utilization  by  DECnet:  100  X 


"Node  Application** 

This  node  will  use  DECnet  for  all  uses  listed  as  applicable  under 
Link  Description  15*  plus  act  as  an  EWNET  Routing  node. 
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Mode  Description 


Node  Name:  Second  Floor  Node  Node  Number:  2 

Location:  Robins  AFB 
Expected  Date  On-Line:  1983 


Operating  System:  RSX-11M 

Languages  Supported:  Fortran  and  Pascal 

Other  Layered  S/W  Products: 

A/D  Scanning? 

D/A  Conversion? 

Graphics? 

27  80 ,37  80  .HASP  ,3  27 1  .SNA? 

Other  Interrupt  Intensive  S/W? 


DECnet  Version:  3.0 


NO 

NO 

NO 

NO 

NO 


CPU:  PDP-11/70 


Main  Memory:  2048  K  bytes  MOS 


Terminals:  Number 

2 

Other  Peripherals: 

Number 

1 

1 

1 

3 

Total  Number  of  Links:  3 


Type  Speeds 

VT-100  9600  baud 


Type 
DR- 11 
LA-120 
LP-11 
RWM-03 


Total  Throughput:  (Bits/Second) 

IN  OUT 

Average:  125  R  125  K 

Peak:  125  K  125  K 


Expected  CPU  Utilization  by  DECnet:  100  1 


“Node  Application” 

This  node  will  use  DECnet  for  all  uses  listed  as  applicable  under 
Link  Description  15*  plus  act  as  an  EWNET  Routing  node. 
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Unde  Ppacription 


Node  Name:  Third  Floor  Node 
Location:  Robin*  AFB 
Expected  Date  On-Line:  1983 


Node  Number:  3 


Operating  System:  RSX-11M 

DECnet  Versi 

Languages  Supported:  Fortran 

and  Pascal 

Other  Layered  S/W  Products: 

A/D  Scanning? 

NO 

D/A  Conversion? 

NO 

Graphics? 

NO 

27 80 ,37 80 .HASP, 

3271.SKA? 

NO 

Other  Interrupt 

Intensive 

S/W?  NO 

CPU:  PDP-11/70 

Main  Memory 

Terminals:  Number 

Type 

Speeds 

2 

VT-100 

9600  baud 

Other  Peripherals: 

Number 

Type 

1 

DR- 11 

1 

LA-120 

1 

LP-11 

3 

RVM-03 

Total  Number  of  Links:  3 

Total  Throughput:  (Bits/Second) 

IN 

OUT 

Average : 

125  K 

125  K 

Peak: 

125  K 

125  K 

3.0 


Expected  CPU  Utilisation  by  DECnet:  100  Z 


"Node  Application** 

This  node  will  use  DECnet  for  all  uses  listed  as  applicable  under 
Link  Description  15*  plus  act  as  an  EWNET  Routing  node. 
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Peripheral  Diiacriptions  (Ref.  3:18-20) 


VT-100 

s 

Standard  CRT  with  Advance  Video 

VT-125 

= 

Graphic a  CRT 

TEX -40 27 

= 

Graphics  CRT 

LA-120 

s 

180  Character  Hard-Copy  Terminal 

RJM-02 

= 

67  M  byte  Freestanding  Disc*  Controller*  and  Drive 
PDP-11/34 

RWM-03 

= 

67  M  byte  Freestanding  Disc*  Controller*  and  Drive 
PDP-11/70 

REM-03 

= 

67  M  byte  Freestanding  Disc*  Controller*  and  Drive 
VAX-11/780 

TEE- 16 

= 

800/1600  BPI*  45  IPS*  9  Track  Mag  Tape  Controller  and 
Drive.  VAX-11/780 

TJE-16 

= 

800/1600  BPI*  45  IPS*  9  Track  Mag  Tape  Controller  and 
Drive.  PDP-11/70  and  PDP-11/34 

LP-11 

s 

600  LPM  Line  Printer 

DR- 11 

s 

DMA  Onibus  Interface 

Yifca 
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software  system  requirements.  Structured  Analysis  was  used  to  produce  a 
structured  specification  for  application,  transport,  network,  and  data  link 
protocol  level  requirements.  Digital  Equipment  Corporation's  'DECnet"  Phase  II 
and  Phase  III  network  configurations  were  combined  together  to  form  this  unique 
Electronic  Warfare  Network  (EWNET).  The  node  network  uses  a  loop  topology  with 

la  star  of  up  to  seven  hosts  connected  to  each  node.  The  nodes  are  implemented 
using  Digital  Equipment  Corporation's  PDP-11/70  computers.  Initially,  the  net¬ 
work  will  include  fourteen  Integrated  Support  Station  computers  which  are  either 
Digital  VAX-11 /780s  cr  Digital  PDP-11 /34s.  These  computers  will  be  connected  to 
the  nodes  using  duplex  fibier  optic  links  supporting  transmission  rates  up  to 
1  Mbs.  The  Phase  II  DECnet  protocol  was  selected  to  provide  the  file  transfer 
and  data  transport  protocols  in  conjunction  with  a  basic  routing  algorithm  at 
each  host,  while  the  Phase  III  DECnet  protocol  was  selected  to  provide  these 
functions  at  a  higher  level  in  the  nodes.  The  selection  of  the  above  topology 
in  conjunction  with  the  d'  scribed  protocol  structure  keeps  any  one  host  from 
degrading  the  network  if  the  host  should  fail.  All  Integrated  Support  Station 
common  off-line  functions,  common  databases,  and  commonly  used  support  software  i 
tools  are  hosted  on  the  node  computer  for  easy,  universal  access,  allowing  for 
a  degree  of  standardization.  ! 
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